原文地址:http://www.cnblogs.com/zhouej/archive/2012/03/25/2379646.htmlphp
下面的內容包含了大部分uWSGI的配置選項,這些配置選項的列舉沒有特定的順序。每個選項均可以使用在任何一種支持的配置方式裏(如命令行參數、環境變量、xml文件、ini文件、yaml格式文件以及LDAP)。有些選項的使用須要某些插件的支持,這些插件的名字都會在文檔裏有說明。html
文檔中的例子使用了多種形式的配置方式來讓使用者更好的理解uwsgi的工做方式。node
若是你剛開始接觸uWSGI,你最好是先看一下快速開始 和 例子 ,這些對實際使用過程的中的一些選項作了舉例說明,另外下面列舉的很是多的配置選項說明對於新手的閱讀可能有一點吃力。python
當使用某一種配置風格或者將一種風格轉換另外一個風格時,須要注意一下規則:linux
命令行參數(command line args):須要給選項增長「--」前綴ios
例如socket選項:nginx
--socket <path/address>
環境變量(environment variable):選項名都要換成大寫,而且加上「UWSGI_」前綴,全部原來選項名中的「-」都要換成下劃線「_」web
例如max-vars選項將變成:ajax
UWSGI_MAX_VARS="<n>"
xml文件:xml文件中的根結點應該是<uwsgi>,全部的選項值是做爲文本節點。標識符類型的選項能夠沒有對應的值。算法
socket選項和master選項能夠以下配置:
<uwsgi>
<socket>127.0.0.1:3031</socket>
<master/>
</uwsgi>
ini文件:配置域應該是uwsgi,標識符類型的選項的值能夠設爲true或者1。
socket選項和master選項能夠以下配置:
[uwsgi]
socket = 127.0.0.1:3031
master = true
yaml格式文件:根元素須要設置爲uwsgi,標識符類型的選項的值能夠設爲true或者1。
socket選項和master選項能夠以下配置:
uwsgi:
socket: 127.0.0.1
master: 1
lda格式:這個格式比較複雜,你應該查閱專門的wiki文檔。見useLDAP。
深呼吸,如今咱們開始。
指定uwsgi的客戶端將要鏈接的socket的路徑(使用UNIX socket的狀況)或者地址(使用網絡地址的狀況)。你最多能夠同時指定8個socket選項。當使用命令行變量時,可使用「-s」這個縮寫。
--socket /tmp/uwsgi.sock
以上配置將會綁定到 /tmp/uwsgi.sock 指定的UNIX socket
-s 127.0.0.1:1717
以上配置會綁定到ipv4地址127.0.0.1的1717端口
[uwsgi]
socket = 127.0.0.1:1717
socket = 127.0.0.1:2626
以上配置會綁定到ipv4地址127.0.0.1的1717端口以及ipv4地址127.0.0.1的2626端口。
設置默認的通訊協議(uwsgi,http,fastcgi)
--protocol <protocol>
爲預先派生模式設置工做進程的數量。這個設置是你的app能實現簡單而且安全的併發能力的基礎。你設置的工做進程越多,你就能越快的處理請求。每個工做進程都等同於一個系統進程,它消耗內存,因此須要當心設置工做進程的數量。若是你設置的數量太多,就有多是系統崩潰。
當你使用命令行參數時,你可使用簡化命令「-p」
--processes 8
以上配置會產生8個工做進程
--workers 4
以上配置會產生4個工做進程
-p 8
以上會產生8個工做進程
<uwsgi>
<workers>3</workers>
</uwsgi>
這個配置會產生3個工做進程
這個選項會設置harakiri超時時間(能夠看wiki首頁的相關內容)。若是一個請求花費的時間超過了這個harakiri超時時間,那麼這個請求都會被丟棄,而且當前處理這個請求的工做進程會被回收再利用(即重啓)。
--harakiri 60
這個設置會使uwsgi丟棄全部須要60秒才能處理完成的請求。
When a request is killed by harakiri you will get a message in the uWSGI log. Enabling this option will print additional info (for example in Linux will be reported the current syscall)
當一個請求被harakiri殺掉之後,你將在uWSGI日誌中獲得一條消息。激活這個選項會打印出額外的信息(例如,在linux中會打印出當前的syscall)。
--harakiri-verbose
以上配置會開啓harakiri的額外信息。
set the harakiri mode for spooler tasks
爲spooler任務設置harakiri模式
--spooler-harakiri <n> option
爲mule進程設置harakiri模式
--mule-harakiri <n>
加載指定的xml配置文件。當使用命令行參數時,可使用簡化命令「-x」。在xml配置文件中,你能夠有多個「<uwsgi>」節,不一樣的節之間用id屬性區分。經過在文件名後面增長id(使用冒號分隔)來選擇應用哪一個「<uwsgi>」節。
--xml /etc/myapp.xml
以上配置會加載/etc/myapp.xml這個配置文件。
--xml /etc/myapp.xml:django
以上命令會使用/etc/myapp.xml這個配置文件中的「django」這個節做爲配置選項
這個文件內容能夠像以下這樣:
<all_the_apps>
<uwsgi id="turbogears">
<socket>/tmp/tg.sock</socket>
</uwsgi>
<uwsgi id="django">
<socket>/tmp/django.sock>
</uwsgi>
</all_the_apps>
這種狀況下,根節點能夠是任何你想要的名字(這就容許你能夠將uwsgi這個配置節加到其餘xml文件中)
若是在命令行的最後一個參數以「.xml」結尾,那麼就隱含將加載該xml文件做爲配置。
/usr/bin/uwsgi /etc/myapp.xml
以上命令會使uWSGI自動加載 /etc/myapp.xml配置文件。
設置一個佔位符
--set KEY=VALUE
使進程在後臺運行,並將日誌打到指定的日誌文件或者udp服務器
--daemonize /var/log/uwsgi.log
這個指令會讓uWSGI在後臺運行並將日誌打到 /var/log/uwsgi.log文件中。
[uwsgi]
daemonize = 192.168.0.100:4000
這個配置將會使uWSGI在後臺運行,而且將日誌消息發送給監聽192.168.0.100:4000這個地址的udp服務器。見UdpLogging。
發送一個SIGINT信號給<pidfile>文件中的pid標識的uWSGI
--stop <pidfile>
發送一個SIGHUP信號給<pidfile>文件中的pid標識的uWSGI
--reload <pidfile>
設置socket的監聽隊列大小(默認:100)。
每個socket都有一個相關聯的隊列,請求會被放入其中等待進程來處理。當這個隊列慢的時候,新來的請求就會被拒絕。
隊列大小的最大值依賴於系統內核。
設置uwsgi客戶端可以傳遞給uwsgi的變量的最大數量值。這只是一個安全相關的值,大多數狀況下你是不須要設置它的。
設置用於uwsgi包解析的內部緩存區大小。默認是4k。
若是你打算接受一個擁有不少請求頭的大請求,你能夠增長這個值到64k。
--buffer-size 32768
這個命令會容許uWSGI服務器接收最大爲32k的uwsgi包,再大的包就會被拒絕。
enable memory usage report. This will print in the request log information about RSS and address space usage.
開啓內存使用狀況報告。這將打印請求相關的內存和虛擬內存的使用狀況。
<uwsgi>
<memory-report/>
</uwsgi>
開啓cgi模式。響應將再也不是HTTP可用的響應,而是cgi響應(會增長Status:這個請求頭)
unix socket是個文件,因此會受到unix系統的權限限制。若是你的uwsgi客戶端沒有權限訪問uWSGI socket,你能夠用這個選項設置unix socket的權限。
當在xml配置文件中只是用這個選項做爲一個標識符,那麼會將權限設爲666,不然就是設置爲指定的權限值。
<uwsgi>
<chmod-socket/>
</uwsgi>
這個配置會將socket文件的權限設爲666
<uwsgi>
<chmod-socket>644</chmod-socket>
</uwsgi>
這個配置會將socket文件的權限設爲644
容許綁定到一個不存在的網絡地址。
當你將一個uWSGI實例綁定到多個socket,你能夠指定某些工做進程到某些socket來提升服務質量。
[uwsgi]
socket = /tmp/uwsgi0.sock
socket = /tmp/uwsgi1.sock
workers = 5
map-socket = 0:1,2,3
map-socket = 1:4,5
這個配置會使工做進程1,2和3綁定到第一個socket,而工做進程4和5綁定到第二個socket。
若是你讓多個app都由同一個uWSGI實例來處理,你能夠很方便地爲每個app分配資源。
容許用內嵌的語言啓動線程。這將容許你在app程序中產生一個子線程。
一些語言(好比python)有「多解釋器」的概念。他們容許在同一個進程中獨立存在不一樣的app。若是你不想用這個特性,你可使用該選項。
這個選項將自動給uWSGI的進程設置一些有意義的名字,例如「uWSGI master」, 「uWSGI worker 1」, 「uWSGI worker 2」。
這個選項爲進程名指定前綴。
--procname-prefix <value>
例如:
--procname-prefix test
那麼,進程名將變成「testuWSGI master」、「testuWSGI worker 1」、「testuWSGI worker 2」等,test與uWSGI之間是連在一塊兒的,可讀性較差。
用這個選項給進程名指定前綴時,前綴和進程名之間有空格分隔。
--procname-prefix-spaced <value>
例如:
--procname-prefix-spaced test
那麼,進程名將變成「test uWSGI master」、「test uWSGI worker 1」、「test uWSGI worker 2」等,比procname-prefix的可讀性好一點。
屢次使用,後一次使用將覆蓋前一次,即以最後一次使用爲準。
這個選項爲進程名增長指定的後綴。
--procname-append <value>
例如:
--procname-append test
那麼,進程名將變成「uWSGI mastertest」、「uWSGI worker 1test」、「uWSGI worker 2test」等,test與master或者一、2是連在一塊兒的,可讀性也比較差。
屢次使用,後一次使用將覆蓋前一次,即以最後一次使用爲準。
爲進程指定名字。
--procname <value>
例如:
--procname test
那麼,全部進程的名字(包括主進程和工做進程)都變成了「test」。只能根據PPID來判斷哪一個是主進程(主進程的PPID爲1)。
注意,使用procname-prefix、procname-prefix-spaced以及procname-append都能在當前選項修改生效的基礎上增長前綴和後綴。
屢次使用,後一次使用將覆蓋前一次,即以最後一次使用爲準。
指定主進程的名字。
--procname-master <value>
例如:
--procname-master test
那麼,主進程的名字就變成了「test」。
注意,使用procname-prefix、procname-prefix-spaced以及procname-append都能在當前選項修改生效的基礎上增長前綴和後綴。
屢次使用,後一次使用將覆蓋前一次,即以最後一次使用爲準。
另外,該選項將覆蓋procname對主進程名字的修改。全部能夠把procname和procname-master配合使用,達到修改全部進程的名字的同時又能將主進程和工做進程區分開的效果。
啓動主進程。
開啓uWSGI的Emperor模式。
開啓emperor的tyrant模式。見tyrant。
爲emperor模式開啓一個uWSGI的統計服務器。見stats server。
--emperor-stats <addr>
start the emperor before jailing and privileges drop
爲emperor開啓bloodlord模式。見broodlord。
set virtualhost name in AMQP emperor mode
set username name in AMQP emperor mode
set password name in AMQP emperor mode
set the number of milliseconds (default 1000) to wait before each vassal's fork()
<filename> will be executed when the emperor starts the vassals
--vassals-start-hook <filename>
<filename> will be executed when the emperor stop the vassals
--vassals-stop-hook <filename>
UNKNOWN
--auto-snapshot 1
設置在平滑的重啓(直到接收到的請求處理完才重啓)一個工做子進程中,等待這個工做結束的最長秒數。
--reload-mercy 8
這個配置會使在平滑地重啓工做子進程中,若是工做進程結束時間超過了8秒就會被強行結束(忽略以前已經接收到的請求而直接結束)。
迫使在重啓過程當中結束uWSGI的棧。這個選項只在某系特殊狀況有用。
打印幫助信息到標準輸出,而後退出。
開啓reaper模式。沒處理一個請求,服務器就會調用waitpid(-1)來清除全部的殭屍進程。若是你在你的app中生成了子進程,結束後又成爲了不少殭屍進程,那麼你能夠開啓這個選項。但遇到這種狀況你更應該修復你這種子進程的使用方式(若是能夠的話)。
爲每一個工做進程設置請求數的上限。當一個工做進程處理的請求數達到這個值,那麼該工做進程就會被回收重用(重啓)。你可使用這個選項來默默地對抗內存泄漏(儘管這類狀況使用reload-on-as和reload-on-rss選項更有用)。
[uwsgi]
max-requests = 1000
上述配置設置工做進程沒處理1000個請求就會被回收重用。
爲全部的socket操做設置內部超時時間(默認4秒)。
--socket-timeout 10
這個配置會結束那些處於不活動狀態超過10秒的鏈接。
create <n> locks for you to use. see locks
建立n個鎖以供使用。見locks。
--locks <n>
這個選項將開啓SharedArea。這將容許一個比較低級的內存共享。若是你但願用一個更好用更友好的共享系統,能夠看CachingFramework。
--sharedarea 10
這個配置將建立一個10個頁的共享內存區。
開啓共享cache。見CachingFramework。
設置cache的塊大小,默認爲65536字節。最好設置爲4096的倍數。
開啓該選項,使uWSGI的cache中的內容可以被長久的保存。
設置msync()這個函數的調用頻率,調用msync()這個函數可以將cache中的內容寫到磁盤上。
UNDOCUMENTED
UNDOCUMENTED
UNDOCUMENTED
UNDOCUMENTED
在指定的目錄下創建一個Spooler。
[uwsgi]
spooler = /home/foo/spooler
這個配置會將spooler文件保存到/home/foo/spooler directory目錄下。
這個選項容許你爲每個spooler任務定義一個公共的目錄。
--spooler-chdir <directory>
增長一個mule進程。見Mules。
不記錄請求信息的日誌。只記錄錯誤以及uWSGI內部消息到日誌中。
在失去權限前,將pid寫到指定的pidfile文件中。
在失去權限後,將pid寫到指定的pidfile文件中。
使用chroot()改變默認目錄到指定目錄。
在uWSGI服務器將要運行的狀況下,設置gid。
在uWSGI服務器將要運行的狀況下,設置uid。
設置ini配置文件的路徑。
--ini <inifile>
設置yaml配置文件的路徑。
--yaml <yamlfile>
設置json格式的配置文件的路徑。
格式遵循的規則跟其餘支持的配置格式同樣(支持正整數,布爾數和數組):
{
"uwsgi": {
"http": ":8080",
"master": true,
"module": "werkzeug.testapp:test_app",
"workers": 8,
"pythonpath": [ "/foo", "/bar" ]
}
}
爲了使用JSON,你須要jansson庫。默認狀況下,會自動檢測到庫的所在位置,可是你也能夠buildconf或者默認ini配置文件來指定。emperor已經被擴展支持.js文件了。
--json <jsonfile>
從ldap服務器加載配置文件。見UseLdap(目前無文檔)。
dump the LDAP schema (old-style format)
dump the LDAP schema in LDIF format (new openldap)
初始化uWSGI服務器,而後當初始化工做完成時當即結束(能夠用來做測試)。
默認狀況下(這個配置有效的狀況下)uWSGI會延遲調用accept()去獲取請求,直到客戶端發送請求數據過來(這種方法可以提升性能和安全性)。可使用這個選項來禁用這個特性。
經過使用POSIX/UNIX的setrlimit()函數來限制每一個uWSGI進程的虛擬內存使用數。
--limit-as 256
這個配置會限制uWSGI的進程佔用虛擬內存不超過256M。若是虛擬內存已經達到256M,並繼續申請虛擬內存則會使程序報內存錯誤,本次的http請求將返回500錯誤。
英文文檔中還解釋了address space其實就是虛擬內存。
在使用這個選項前先理解這個頁面的內容: http://en.wikipedia.org/wiki/Virtual_memory
當一個工做進程的虛擬內存佔用超過了限制的大小,那麼該進程就會被回收重用(重啓)。
--reload-on-as 128
這個配置會重啓全部佔用虛擬內存超過128M的工做進程。當工做進程所以重啓時,本次請求的響應不會受影響,返回正常結果。
跟reload-on-as的效果相似,不過這個選項控制的是物理內存。你能夠同時使用這2個選項:
uwsgi:
reload-on-as: 128
reload-on-rss: 96
這個配置會致使全部佔用128M以上虛擬內存或者超過96M物理內存的工做進程重啓。
當工做進程所以重啓時,本次請求的響應不會受影響,返回正常結果。
主進程會重啓佔用虛擬內存超過<n>M的工做進程。
--evil-reload-on-as <n>
主要效果跟evil-reload-on-as同樣,可是這個選項控制的是非共享物理內存。
--evil-reload-on-rss <n>
當uWSGI運行在多代理下時,會將正確的客戶端IP打到日誌中。
當文件改變時,優雅的重啓uWSGI。
uwsgi:
touch-reload: /tmp/reload.txt
若是你使用下面的命令:
touch /tmp/reload.txt
那麼uWSGI服務器就會優雅的重啓。
限制HTTP請求體的大小。uWSGI經過CONTENT_LENGTH字段值來得到請求體的大小。
--limit-post 65536
將不容許請求體超過64k的請求。
在沒有主進程的狀況下自動結束工做進程。
設置進程的系統調度優先級。
<uwsgi>
<prio>20</prio>
</uwsgi>
設置CPU的親和性(只對於Linux系統)。見 http://lists.unbit.it/pipermail/uwsgi/2011-March/001594.html
開啓http請求體的緩存。uWSGI將全部大於限定大小的HTTP請求體保存到磁盤中。
[uwsgi]
post-buffering = 8192
上述配置會使uWSGI將全部大於8K的HTTP請求體都緩存到磁盤中。Rack應用程序須要這個選項,由於Rack應用程序須要一個可回退的輸入流。
爲post的緩存設置內部的緩衝區大小。(這個分配的內存是用來讀取socket流的字節塊)
post-buffering-bufsize 65536
上述配置會使uWSGI分配一個64k的socket的recv()函數的緩存區。對一個128k的請求體來講,須要使用2個這樣的緩存區。
這是一個比較高級的選項,你可能永遠不會用到。
開啓嵌入的上傳進度報告。你傳入一個uWSGI有寫權限的目錄,那麼每個上傳的JSON文件都會放到該目錄下,開啓這個選項後,就會報告當前的上傳狀態。你可使用ajax去讀取這些文件,因此配置好你的web服務器容許對該目錄的訪問。
--upload-progress /var/www/progress
用戶經過以下的url上傳一個文件。
http://uwsgi.it/upload?X-Progress-ID=550e8400-e29b-41d4-a716-446655440000
uWSGI在請求url中找到X-Progress-ID,而後在 /var/www/progress下建立一個文件:
550e8400-e29b-41d4-a716-446655440000.js
該文件的內容以下:
{ "state" : "uploading", "received" : 170000, "size" : 300000 }
假設你已經在你的web服務器中將/progress這個URI映射到了/var/www/progress這個目錄,那麼你能夠經過ajax pointing來得到那些json數據。
/progress/550e8400-e29b-41d4-a716-446655440000.js
極可能你的web服務器已經擁有一個類似的功能了,可是若是你須要改進原有的功能(或者只是想有更多的控制),那麼就將該功能委託給uWSGI服務器。
默認狀況下,當uWSGI沒有找到SCRIPT_NAME指定的app時,會使用默認的app(大多數狀況,默認的app都位於/目錄下)。開啓這個選項,在沒有可用的app時會返回一個錯誤。
若是由於某些緣由,你的web服務器不能處理SCRIPT_NAME,你能夠強制uWSGI自動重建PATH_INFO。
啓動一個udp服務器,主要用在snmp或者爲UdpLogging提供一個共享的打日誌服務器。
內部選項,用於第三方插件。
加入指定的集羣。見Clustering。
你能夠獲得一個集羣裏的節點列表,而不須要加入這個集羣。
--cluster-nodes 225.1.1.1:1717
使用上述選項能獲得225.1.1.1:1717這個集羣的全部節點。這個列表提供給uwsgi內部均衡負載api用的。
優雅地重啓整個集羣。
--cluster 225.1.1.1:1717 --cluster-reload
使用上述選項會重啓225.1.1.1:1717這個集羣中的全部節點。
給一個集羣的全部節點服務器發送一個日誌信息。
--cluster 225.1.1.1:1717 --cluster-log "Hello World"
上述選項會在全部的節點日誌文件中打印出"Hello World"
訂閱一個SubscriptionServer,你能夠經過配置屢次該選項來達到訂閱多個服務器的目的。
[uwsgi]
subscribe-to = 192.168.0.1:2626:unbit.it
subscribe-to = 192.168.0.2:2626:uwsgi.it
一個高級選項,插件做者會用到,或者用於一些特殊的需求。該選項容許服務器在啓動早期建立一個socket,在失去特權或者被監禁的時候依然能使用它。
啓動一個SNMP服務器。見UseSnmp
set the snmp community string
主進程每秒都會進行一次掃描。若是須要你能夠加長這個掃描時間。不建議。
若是uWSGI的二進制文件路徑沒有加到系統環境變量中,你可使用這個選項強制改變二進制的查找路徑,那麼重載系統和Emperor都能輕易找到可執行的二進制文件。
開啓異步模式。見AsyncSupport。
將日誌打到一個指定的文件或者udp服務器。
將日誌打到系統日誌上,而再也不打到日誌文件中。
傳入一個參數,使uwsgi使用這個參數做爲程序名,用在系統日誌開始部分裏。
--log-syslog mywebapp
委託主進程來負責日誌的寫操做(這將把全部的日誌IO操做都放到一個進程中)。對使用高級的IO調度策略的系統來講是頗有用的。
在每個日誌行中都打印時間信息。你能夠傳入一個strftime()格式的參數,來格式化時間的格式。
打印請求大小爲0的請求。
使用微秒做爲日誌中響應時間的單位(默認是毫秒)。
以root權限運行uWSGI的主進程。
在失去權限前,使用chdir()到指定目錄。
在失去權限後,使用chdir()到指定目錄。
等每個工做進程都生成之後才加載應用程序。
延遲啓動工做進程直到第一個請求到來。當第一個請求來時就會啓動預先設置個數的工做進程。
若是沒有設置工做進程數,那麼最多隻會啓動一個工做進程。
一個高階的cheap模式,這個選項將在啓動的時候只分配n個工做進程,並將使用多種算法來實現適應性的進程啓動。
在啓動的時候至少會分配一個工做進程,即及時設置n爲0,也會在最開始啓動一個工做進程。
若是當前工做進程不足以處理收到的請求,那麼就會按請求量按需啓動其餘的工做進程,直到工做進程達到預先設置的個數。
若是沒有設置工做進程數,那麼只會在剛啓動的時候啓動一個工做進程,以後將再也不啓動其餘進程。
--cheaper <n>
在通過<secs>秒的不活躍狀態後銷燬工做進程(這時就進入了cheap模式),只會剩下主進程。
若是有cheaper選項,那麼就進入cheaper模式,以後收到第一個請求就會啓動工做進程,啓動的個數由cheaper選項裏配置的n決定。
--idle <secs>
容許同一個進程加載多個app。
--mount /pinax=/var/www/pinax/deploy/pinax.wsgi
allows grunt processes
開啓線程操做模式。你必須指定每一個工做進程的線程數。
--threads 40 --workers 2
這個配置會致使生成2個工做進程,每一個工做進程有40個子線程。
開啓虛擬主機模式。見VirtualHosting
默認狀況下,虛擬主機模式使用SERVER_NAME做爲主機名的關鍵字。若是你但願使用HTTP_HOST,那就加這個選項。
uWSGI會在移交控制權給指定處理者以前檢查該選項指定的目錄。
uWSGI會檢查這個目錄,若是恰好請求的PATH_INFO有一個文件在這個目錄,那麼uWSGI就會提供這個文件。
--check-static /var/www/example.com
使用上述配置,若是客戶端請求foo.png,而該文件又剛好存在於/var/www/example.com/foo.png,那麼uWSGI就會直接用指定的方法提供這個文件(默認是用sendfile ())。
映射一個資源到靜態文件區。
[uwsgi]
static-map = /media=/var/www/django/contrib/admin/media
static-map = /images=/var/www/example.com/images
不管何時一個PATH_INFO匹配到配置文件中的資源,uWSGI會直接用指定的方法提供這個文件(默認是用sendfile ())。
在目錄索引中用到的靜態文件的文件名。
static-index = index.html
若是請求/doc/,那麼uWSGI將檢查/doc/index.html,若是存在就會提供給客戶端。
設置靜態服務模式:
1.x-sendfile:將使用X-Sendfile頭(apache, Cherokee, lighttpd)
2.x-accel-redirect:將使用X-Accel-Redirect header(nginx)
3.default:使用sendfile()
--file-serve-mode x-sendfile
檢查 uWSGI cache 中是否存在PATH_INFO指定的內容,若是存在就提供該內容。
給uWSGI的socket設置close-on-exec標識,這將避免在一個請求中產生額外的進程,來繼承socket文件的描述符。
普通選項,app可使用uwsgi.mode來得到這個選項值。
設置一個系統環境變量。
[uwsgi]
env = DJANGO_SETTINGS_MODULE=mysite.settings
這個配置將會設置一個環境變量DJANGO_SETTINGS_MODULE,它的值爲mysite.settings
當服務器退出的時候自動刪除unix socket文件和pid文件。
run the server in <group> cgroup (Linux only)
設置cgroup選項(僅限於Linux)
--cgroup-opt KEY=VAL
容許多個實例綁定到同一個地址。
設置LoopEngine(高級選項)
funny option to map a new executable to a uWSGI worker. You can run a php fastcgi server pool in this way
/usr/bin/uwsgi --workers 4 --worker-exec /usr/bin/php53-cgi
給uWSGI主進程附加一個進程,並容許主進程控制、監控、重啓這個進程。一個比較典型的使用是給主進行附加一個memcached實例。
[uwsgi]
master = true
attach-daemon = memcached
加載指定的插件。
--plugins psgi,greenlet
這個配置將加載psgi插件和greenlet插件。
限制客戶端只能訪問modifiers的子集。
--allowed-modifiers 0,111
這個配置將只容許客戶端訪問WSGI處理程序和cache處理程序。
打印全部可用的選項,而後退出。
以ini文件格式打印當前的配置。
將在解析配置文件的工程中打印一個字符串。
[uwsgi]
print = foo
將在服務器啓動的時候打印"foo"。
打印出uWSGI的版本,而後退出。
加載指定的WSGI文件(與Graham的mod_wsgi形式兼容)
把計算一個字符串的值做爲WSGI的入口。
<uwsgi>
<eval>
def application(e, sr):
pass
</eval>
</uwsgi>
加載指定的python WSGI模塊(模塊路徑必須在PYTHONPATH裏)
設置在收到請求時,uWSGI加載的模塊中哪一個變量將被調用,默認是名字爲「application」的變量。
測試一個模塊是否能被成功的加載。
爲python程序設置指定的虛擬環境變量。
--virtualenv /apps/env001
使用在/apps/env001的虛擬環境變量。
給PYTHONPATH 增長一個目錄(或者一個egg),你能夠最多使用該選項64次。
[uwsgi]
pp = myapp/lib
pp = trac.egg
該選項容許python模塊的重映射。見PymoduleAlias。
set the python sys.argv
設置python的系統參數(sys.argv)
--pyargv "one two three"
該配置會將sys.argv 設爲('one','two','three')。
設置python爲最優化級別(要當心)
use paste.deploy to load a WSGI app
使用paste.deploy 來加載一個WSGI程序。
uwsgi --paste config:/foo/development.ini
ini和paste這2個選項的簡化,在文件解析完以後,將使用一樣的文件做爲paste.deploy的配置文件。
load a paste.deploy config file containing uwsgi section (load loggers too)
在你的瀏覽器中打印出traceback信息,而不是在日誌文件中(不要在實際產品中使用這個選項)。
不加載python的site.py模塊。
工具性的選項。ping一個uwsgi服務器,若是ping成功,難麼進程就會退出,並返回0,不然返回一個大於0的值。
/usr/bin/uwsgi --ping 192.168.0.100:1717
將ping在192.168.0.100:1717的uWSGI服務器。
設置ping的超時時間(默認是3秒)。ping的等待時間超過指定的秒數後就認爲該uWSGI實例已失效。
/usr/bin/uwsgi --ping 192.168.0.100:1717 --ping-timeout 10
將設置ping的超時時間爲10秒。
做nagios檢查。
Run the fastrouter (it is a uwsgi proxy/load balancer) on specific address
在指定的地址上運行fastrouter(這是一個uwsgi的代理、負載均衡)。
[uwsgi]
fastrouter = 127.0.0.1:3017
在127.0.0.1:3017這個地址上運行fastrouter
check the uwsgi cache to get hostname:address mapping
use a filesystem pattern to get hostname:address mapping
limit the max number of async events the fastrouter can return in one cycle
add a SubscriptionServer to the fastrouter to build the hostname:address map
設置fastrouter的內部超時時間。
開啓嵌入的http服務器、路由、網關、負載均衡、代理。
enable the SubscriptionServer for clustering and massive hosting/load-balancing
設置內部http的socket超時時間。
enable uGreen as suspend/resume engine. See uGreen