【轉載】uWSGI配置翻譯

時間 2019-11-18

標籤轉載 uwsgi 配置翻譯欄目 Nginx 简体版

原文原文鏈接

英文原版: http://uwsgi-docs.readthedocs.io/en/latest/Options.htmlphp

轉載地址: http://www.cnblogs.com/zhouej/archive/2012/03/25/2379646.htmlhtml

uWSGI參考資料（1.0版本的配置選項列表）

下面的內容包含了大部分uWSGI的配置選項，這些配置選項的列舉沒有特定的順序。每個選項均可以使用在任何一種支持的配置方式裏（如命令行參數、環境變量、xml文件、ini文件、yaml格式文件以及LDAP）。有些選項的使用須要某些插件的支持，這些插件的名字都會在文檔裏有說明。node

文檔中的例子使用了多種形式的配置方式來讓使用者更好的理解uwsgi的工做方式。python

若是你剛開始接觸uWSGI，你最好是先看一下快速開始和例子，這些對實際使用過程的中的一些選項作了舉例說明，另外下面列舉的很是多的配置選項說明對於新手的閱讀可能有一點吃力。linux

配置風格的簡單介紹

當使用某一種配置風格或者將一種風格轉換另外一個風格時，須要注意一下規則：ios

命令行參數（command line args）：須要給選項增長「--」前綴nginx

例如socket選項：web

--socket <path/address>

環境變量（environment variable）：選項名都要換成大寫，而且加上「UWSGI_」前綴，全部原來選項名中的「-」都要換成下劃線「_」ajax

例如max-vars選項將變成：算法

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。

無盡的選項列表...

深呼吸，如今咱們開始。

socket or uwsgi-socket

指定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端口。

protocol

設置默認的通訊協議（uwsgi，http，fastcgi）

--protocol <protocol>

processes or workers

爲預先派生模式設置工做進程的數量。這個設置是你的app能實現簡單而且安全的併發能力的基礎。你設置的工做進程越多，你就能越快的處理請求。每個工做進程都等同於一個系統進程，它消耗內存，因此須要當心設置工做進程的數量。若是你設置的數量太多，就有多是系統崩潰。

當你使用命令行參數時，你可使用簡化命令「-p」

--processes 8

以上配置會產生8個工做進程

--workers 4

以上配置會產生4個工做進程

-p 8

以上會產生8個工做進程

<uwsgi>
    <workers>3</workers>
</uwsgi>

這個配置會產生3個工做進程

harakiri

這個選項會設置harakiri超時時間（能夠看wiki首頁的相關內容）。若是一個請求花費的時間超過了這個harakiri超時時間，那麼這個請求都會被丟棄，而且當前處理這個請求的工做進程會被回收再利用（即重啓）。

--harakiri 60

這個設置會使uwsgi丟棄全部須要60秒才能處理完成的請求。

harakiri-verbose

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的額外信息。

spooler-harakiri

set the harakiri mode for spooler tasks

爲spooler任務設置harakiri模式

--spooler-harakiri <n> option

mule-harakiri

爲mule進程設置harakiri模式

--mule-harakiri <n>

xmlconfig or xml

加載指定的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

設置一個佔位符

--set KEY=VALUE

daemonize

使進程在後臺運行，並將日誌打到指定的日誌文件或者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。

stop

發送一個SIGINT信號給<pidfile>文件中的pid標識的uWSGI

--stop <pidfile>

reload

發送一個SIGHUP信號給<pidfile>文件中的pid標識的uWSGI

--reload <pidfile>

listen

設置socket的監聽隊列大小（默認：100）。

每個socket都有一個相關聯的隊列，請求會被放入其中等待進程來處理。當這個隊列慢的時候，新來的請求就會被拒絕。

隊列大小的最大值依賴於系統內核。

max-vars

設置uwsgi客戶端可以傳遞給uwsgi的變量的最大數量值。這只是一個安全相關的值，大多數狀況下你是不須要設置它的。

buffer-size

設置用於uwsgi包解析的內部緩存區大小。默認是4k。

若是你打算接受一個擁有不少請求頭的大請求，你能夠增長這個值到64k。

--buffer-size 32768

這個命令會容許uWSGI服務器接收最大爲32k的uwsgi包，再大的包就會被拒絕。

memory-report

enable memory usage report. This will print in the request log information about RSS and address space usage.

開啓內存使用狀況報告。這將打印請求相關的內存和虛擬內存的使用狀況。

<uwsgi>
    <memory-report/>
</uwsgi>

cgi-mode

開啓cgi模式。響應將再也不是HTTP可用的響應，而是cgi響應（會增長Status：這個請求頭）

abstract-socket

chmod-socket or chmod

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

freebind (Linux only)

容許綁定到一個不存在的網絡地址。

map-socket

當你將一個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分配資源。

enable-threads

容許用內嵌的語言啓動線程。這將容許你在app程序中產生一個子線程。

single-interpreter

一些語言（好比python）有「多解釋器」的概念。他們容許在同一個進程中獨立存在不一樣的app。若是你不想用這個特性，你可使用該選項。

auto-procname

這個選項將自動給uWSGI的進程設置一些有意義的名字，例如「uWSGI master」，「uWSGI worker 1」，「uWSGI worker 2」。

procname-prefix

這個選項爲進程名指定前綴。

--procname-prefix <value>

例如：

--procname-prefix test

那麼，進程名將變成「testuWSGI master」、「testuWSGI worker 1」、「testuWSGI worker 2」等，test與uWSGI之間是連在一塊兒的，可讀性較差。

procname-prefix-spaced

用這個選項給進程名指定前綴時，前綴和進程名之間有空格分隔。

--procname-prefix-spaced <value>

例如：

--procname-prefix-spaced test

那麼，進程名將變成「test uWSGI master」、「test uWSGI worker 1」、「test uWSGI worker 2」等，比procname-prefix的可讀性好一點。

屢次使用，後一次使用將覆蓋前一次，即以最後一次使用爲準。

procname-append

這個選項爲進程名增長指定的後綴。

--procname-append <value>

例如：

--procname-append test

那麼，進程名將變成「uWSGI mastertest」、「uWSGI worker 1test」、「uWSGI worker 2test」等，test與master或者一、2是連在一塊兒的，可讀性也比較差。

屢次使用，後一次使用將覆蓋前一次，即以最後一次使用爲準。

procname

爲進程指定名字。

--procname <value>

例如：

--procname test

那麼，全部進程的名字（包括主進程和工做進程）都變成了「test」。只能根據PPID來判斷哪一個是主進程（主進程的PPID爲1）。

注意，使用procname-prefix、procname-prefix-spaced以及procname-append都能在當前選項修改生效的基礎上增長前綴和後綴。

屢次使用，後一次使用將覆蓋前一次，即以最後一次使用爲準。

procname-master

指定主進程的名字。

--procname-master <value>

例如：

--procname-master test

那麼，主進程的名字就變成了「test」。
注意，使用procname-prefix、procname-prefix-spaced以及procname-append都能在當前選項修改生效的基礎上增長前綴和後綴。

屢次使用，後一次使用將覆蓋前一次，即以最後一次使用爲準。

另外，該選項將覆蓋procname對主進程名字的修改。全部能夠把procname和procname-master配合使用，達到修改全部進程的名字的同時又能將主進程和工做進程區分開的效果。

master

啓動主進程。

emperor

開啓uWSGI的Emperor模式。

emperor-tyrant

開啓emperor的tyrant模式。見tyrant。

emperor-stats or emperor-stats-server

爲emperor模式開啓一個uWSGI的統計服務器。見stats server。

--emperor-stats <addr>

early-emperor

start the emperor before jailing and privileges drop

emperor-broodlord

爲emperor開啓bloodlord模式。見broodlord。

emperor-amqp-vhost

set virtualhost name in AMQP emperor mode

emperor-amqp-username

set username name in AMQP emperor mode

emperor-amqp-password

set password name in AMQP emperor mode

emperor-throttle

set the number of milliseconds (default 1000) to wait before each vassal's fork()

vassals-start-hook

<filename> will be executed when the emperor starts the vassals

--vassals-start-hook <filename>

vassals-stop-hook

<filename> will be executed when the emperor stop the vassals

--vassals-stop-hook <filename>

auto-snapshot

UNKNOWN

--auto-snapshot 1

reload-mercy

設置在平滑的重啓（直到接收到的請求處理完才重啓）一個工做子進程中，等待這個工做結束的最長秒數。

--reload-mercy 8

這個配置會使在平滑地重啓工做子進程中，若是工做進程結束時間超過了8秒就會被強行結束（忽略以前已經接收到的請求而直接結束）。

exit-on-reload

迫使在重啓過程當中結束uWSGI的棧。這個選項只在某系特殊狀況有用。

help or usage

打印幫助信息到標準輸出，而後退出。

reaper

開啓reaper模式。沒處理一個請求，服務器就會調用waitpid(-1)來清除全部的殭屍進程。若是你在你的app中生成了子進程，結束後又成爲了不少殭屍進程，那麼你能夠開啓這個選項。但遇到這種狀況你更應該修復你這種子進程的使用方式（若是能夠的話）。

max-requests

爲每一個工做進程設置請求數的上限。當一個工做進程處理的請求數達到這個值，那麼該工做進程就會被回收重用（重啓）。你可使用這個選項來默默地對抗內存泄漏（儘管這類狀況使用reload-on-as和reload-on-rss選項更有用）。

[uwsgi]
max-requests = 1000

上述配置設置工做進程沒處理1000個請求就會被回收重用。

socket-timeout

爲全部的socket操做設置內部超時時間（默認4秒）。

--socket-timeout 10

這個配置會結束那些處於不活動狀態超過10秒的鏈接。

locks

create <n> locks for you to use. see locks

建立n個鎖以供使用。見locks。

--locks <n>

sharedarea

這個選項將開啓SharedArea。這將容許一個比較低級的內存共享。若是你但願用一個更好用更友好的共享系統，能夠看CachingFramework。

--sharedarea 10

這個配置將建立一個10個頁的共享內存區。

cache

開啓共享cache。見CachingFramework。

cache-blocksize

設置cache的塊大小，默認爲65536字節。最好設置爲4096的倍數。

cache-store

開啓該選項，使uWSGI的cache中的內容可以被長久的保存。

cache-store-sync

設置msync()這個函數的調用頻率，調用msync()這個函數可以將cache中的內容寫到磁盤上。

queue

UNDOCUMENTED

queue-blocksize

UNDOCUMENTED

queue-store

UNDOCUMENTED

queue-store-sync

UNDOCUMENTED

spooler

在指定的目錄下創建一個Spooler。

[uwsgi]
spooler = /home/foo/spooler

這個配置會將spooler文件保存到/home/foo/spooler directory目錄下。

spooler-chdir

這個選項容許你爲每個spooler任務定義一個公共的目錄。

--spooler-chdir <directory>

mule

增長一個mule進程。見Mules。

disable-logging

不記錄請求信息的日誌。只記錄錯誤以及uWSGI內部消息到日誌中。

pidfile

在失去權限前，將pid寫到指定的pidfile文件中。

pidfile2

在失去權限後，將pid寫到指定的pidfile文件中。

chroot

使用chroot（）改變默認目錄到指定目錄。

gid

在uWSGI服務器將要運行的狀況下，設置gid。

uid

在uWSGI服務器將要運行的狀況下，設置uid。

ini

設置ini配置文件的路徑。

--ini <inifile>

yaml or yml

設置yaml配置文件的路徑。

--yaml <yamlfile>

json

設置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

從ldap服務器加載配置文件。見UseLdap（目前無文檔）。

ldap-schema

dump the LDAP schema (old-style format)

ldap-schema-ldif

dump the LDAP schema in LDIF format (new openldap)

no-server

初始化uWSGI服務器，而後當初始化工做完成時當即結束（能夠用來做測試）。

no-defer-accept

默認狀況下（這個配置有效的狀況下）uWSGI會延遲調用accept()去獲取請求，直到客戶端發送請求數據過來（這種方法可以提升性能和安全性）。可使用這個選項來禁用這個特性。

limit-as

經過使用POSIX/UNIX的setrlimit()函數來限制每一個uWSGI進程的虛擬內存使用數。

--limit-as 256

這個配置會限制uWSGI的進程佔用虛擬內存不超過256M。若是虛擬內存已經達到256M，並繼續申請虛擬內存則會使程序報內存錯誤，本次的http請求將返回500錯誤。

英文文檔中還解釋了address space其實就是虛擬內存。

在使用這個選項前先理解這個頁面的內容: http://en.wikipedia.org/wiki/Virtual_memory

reload-on-as

當一個工做進程的虛擬內存佔用超過了限制的大小，那麼該進程就會被回收重用（重啓）。

--reload-on-as 128

這個配置會重啓全部佔用虛擬內存超過128M的工做進程。當工做進程所以重啓時，本次請求的響應不會受影響，返回正常結果。

reload-on-rss

跟reload-on-as的效果相似，不過這個選項控制的是物理內存。你能夠同時使用這2個選項：

uwsgi:
  reload-on-as: 128
  reload-on-rss: 96

這個配置會致使全部佔用128M以上虛擬內存或者超過96M物理內存的工做進程重啓。

當工做進程所以重啓時，本次請求的響應不會受影響，返回正常結果。

evil-reload-on-as

主進程會重啓佔用虛擬內存超過<n>M的工做進程。

--evil-reload-on-as <n>

evil-reload-on-rss

主要效果跟evil-reload-on-as同樣，可是這個選項控制的是非共享物理內存。

--evil-reload-on-rss <n>

log-x-forwarded-for

當uWSGI運行在多代理下時，會將正確的客戶端IP打到日誌中。

touch-reload

當文件改變時，優雅的重啓uWSGI。

uwsgi:
  touch-reload: /tmp/reload.txt

若是你使用下面的命令：

touch /tmp/reload.txt

那麼uWSGI服務器就會優雅的重啓。

limit-post

限制HTTP請求體的大小。uWSGI經過CONTENT_LENGTH字段值來得到請求體的大小。

--limit-post 65536

將不容許請求體超過64k的請求。

no-orphans

在沒有主進程的狀況下自動結束工做進程。

prio

設置進程的系統調度優先級。

<uwsgi>
    <prio>20</prio>
</uwsgi>

上述配置將設置進程的優先級爲20（具體的值要根據不一樣的系統來設置）。

cpu-affinity

設置CPU的親和性（只對於Linux系統）。見 http://lists.unbit.it/pipermail/uwsgi/2011-March/001594.html

post-buffering

開啓http請求體的緩存。uWSGI將全部大於限定大小的HTTP請求體保存到磁盤中。

[uwsgi]
post-buffering = 8192

上述配置會使uWSGI將全部大於8K的HTTP請求體都緩存到磁盤中。Rack應用程序須要這個選項，由於Rack應用程序須要一個可回退的輸入流。

post-buffering-bufsize

爲post的緩存設置內部的緩衝區大小。（這個分配的內存是用來讀取socket流的字節塊）

post-buffering-bufsize 65536

上述配置會使uWSGI分配一個64k的socket的recv（）函數的緩存區。對一個128k的請求體來講，須要使用2個這樣的緩存區。

這是一個比較高級的選項，你可能永遠不會用到。

upload-progress

開啓嵌入的上傳進度報告。你傳入一個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服務器。

no-default-app

默認狀況下，當uWSGI沒有找到SCRIPT_NAME指定的app時，會使用默認的app（大多數狀況，默認的app都位於/目錄下）。開啓這個選項，在沒有可用的app時會返回一個錯誤。

manage-script-name

若是由於某些緣由，你的web服務器不能處理SCRIPT_NAME，你能夠強制uWSGI自動重建PATH_INFO。

udp

啓動一個udp服務器，主要用在snmp或者爲UdpLogging提供一個共享的打日誌服務器。

multicast

內部選項，用於第三方插件。

cluster

加入指定的集羣。見Clustering。

cluster-nodes

你能夠獲得一個集羣裏的節點列表，而不須要加入這個集羣。

--cluster-nodes 225.1.1.1:1717

使用上述選項能獲得225.1.1.1:1717這個集羣的全部節點。這個列表提供給uwsgi內部均衡負載api用的。

cluster-reload

優雅地重啓整個集羣。

--cluster 225.1.1.1:1717 --cluster-reload

使用上述選項會重啓225.1.1.1:1717這個集羣中的全部節點。

cluster-log

給一個集羣的全部節點服務器發送一個日誌信息。

--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

shared-socket

一個高級選項，插件做者會用到，或者用於一些特殊的需求。該選項容許服務器在啓動早期建立一個socket，在失去特權或者被監禁的時候依然能使用它。

snmp

啓動一個SNMP服務器。見UseSnmp

snmp-community

set the snmp community string

check-interval

主進程每秒都會進行一次掃描。若是須要你能夠加長這個掃描時間。不建議。

binary-path

若是uWSGI的二進制文件路徑沒有加到系統環境變量中，你可使用這個選項強制改變二進制的查找路徑，那麼重載系統和Emperor都能輕易找到可執行的二進制文件。

async

開啓異步模式。見AsyncSupport。

logto

將日誌打到一個指定的文件或者udp服務器。

logfile-chown

log-syslog

將日誌打到系統日誌上，而再也不打到日誌文件中。

傳入一個參數，使uwsgi使用這個參數做爲程序名，用在系統日誌開始部分裏。

--log-syslog mywebapp

log-master

委託主進程來負責日誌的寫操做（這將把全部的日誌IO操做都放到一個進程中）。對使用高級的IO調度策略的系統來講是頗有用的。

logdate or log-date

在每個日誌行中都打印時間信息。你能夠傳入一個strftime()格式的參數，來格式化時間的格式。

log-zero

打印請求大小爲0的請求。

log-slow

log-4xx

log-5xx

log-big

log-sendfile

log-micros

使用微秒做爲日誌中響應時間的單位（默認是毫秒）。

master-as-root

以root權限運行uWSGI的主進程。

chdir

在失去權限前，使用chdir()到指定目錄。

chdir2

在失去權限後，使用chdir()到指定目錄。

lazy

等每個工做進程都生成之後才加載應用程序。

cheap

延遲啓動工做進程直到第一個請求到來。當第一個請求來時就會啓動預先設置個數的工做進程。

若是沒有設置工做進程數，那麼最多隻會啓動一個工做進程。

cheaper

一個高階的cheap模式，這個選項將在啓動的時候只分配n個工做進程，並將使用多種算法來實現適應性的進程啓動。

在啓動的時候至少會分配一個工做進程，即及時設置n爲0，也會在最開始啓動一個工做進程。

若是當前工做進程不足以處理收到的請求，那麼就會按請求量按需啓動其餘的工做進程，直到工做進程達到預先設置的個數。

若是沒有設置工做進程數，那麼只會在剛啓動的時候啓動一個工做進程，以後將再也不啓動其餘進程。

--cheaper <n>

idle

在通過<secs>秒的不活躍狀態後銷燬工做進程（這時就進入了cheap模式），只會剩下主進程。

若是有cheaper選項，那麼就進入cheaper模式，以後收到第一個請求就會啓動工做進程，啓動的個數由cheaper選項裏配置的n決定。

--idle <secs>

mount

容許同一個進程加載多個app。

--mount /pinax=/var/www/pinax/deploy/pinax.wsgi

grunt

allows grunt processes

threads

開啓線程操做模式。你必須指定每一個工做進程的線程數。

--threads 40 --workers 2

這個配置會致使生成2個工做進程，每一個工做進程有40個子線程。

vhost

開啓虛擬主機模式。見VirtualHosting

vhost-host

默認狀況下，虛擬主機模式使用SERVER_NAME做爲主機名的關鍵字。若是你但願使用HTTP_HOST，那就加這個選項。

check-static

uWSGI會在移交控制權給指定處理者以前檢查該選項指定的目錄。

uWSGI會檢查這個目錄，若是恰好請求的PATH_INFO有一個文件在這個目錄，那麼uWSGI就會提供這個文件。

--check-static /var/www/example.com

使用上述配置，若是客戶端請求foo.png，而該文件又剛好存在於/var/www/example.com/foo.png，那麼uWSGI就會直接用指定的方法提供這個文件（默認是用sendfile ()）。

static-map

映射一個資源到靜態文件區。

[uwsgi]
static-map = /media=/var/www/django/contrib/admin/media
static-map = /images=/var/www/example.com/images

不管何時一個PATH_INFO匹配到配置文件中的資源，uWSGI會直接用指定的方法提供這個文件（默認是用sendfile ()）。

static-index

在目錄索引中用到的靜態文件的文件名。

static-index = index.html

若是請求/doc/，那麼uWSGI將檢查/doc/index.html，若是存在就會提供給客戶端。

file-serve-mode

設置靜態服務模式：

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]
env = DJANGO_SETTINGS_MODULE=mysite.settings

這個配置將會設置一個環境變量DJANGO_SETTINGS_MODULE，它的值爲mysite.settings

--cgroup-opt KEY=VAL

reuse-port (BSD only)

容許多個實例綁定到同一個地址。

loop

設置LoopEngine（高級選項）

worker-exec

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

attach-daemon

給uWSGI主進程附加一個進程，並容許主進程控制、監控、重啓這個進程。一個比較典型的使用是給主進行附加一個memcached實例。

[uwsgi]
master = true
attach-daemon = memcached

plugins

加載指定的插件。

--plugins psgi,greenlet

這個配置將加載psgi插件和greenlet插件。

allowed-modifiers

限制客戶端只能訪問modifiers的子集。

--allowed-modifiers 0,111

這個配置將只容許客戶端訪問WSGI處理程序和cache處理程序。

[uwsgi]
print = foo

將在服務器啓動的時候打印"foo"。

version

打印出uWSGI的版本，而後退出。

wsgi-file or file [python plugin required]

加載指定的WSGI文件（與Graham的mod_wsgi形式兼容）

eval [python plugin required]

把計算一個字符串的值做爲WSGI的入口。

<uwsgi>
  <eval>
    def application(e, sr):
    pass
  </eval>
</uwsgi>

module [python plugin required]

加載指定的python WSGI模塊（模塊路徑必須在PYTHONPATH裏）

callable [python plugin required]

設置在收到請求時，uWSGI加載的模塊中哪一個變量將被調用，默認是名字爲「application」的變量。

test [python plugin required]

測試一個模塊是否能被成功的加載。

home or virtualenv or venv or pyhome [python plugin required]

爲python程序設置指定的虛擬環境變量。

--virtualenv /apps/env001

使用在/apps/env001的虛擬環境變量。

pythonpath or python-path or pp [python plugin required]

給PYTHONPATH 增長一個目錄（或者一個egg），你能夠最多使用該選項64次。

[uwsgi]
pp = myapp/lib
pp = trac.egg

pymodule-alias [python plugin required]

該選項容許python模塊的重映射。見PymoduleAlias。

pyargv [python plugin required]

set the python sys.argv

設置python的系統參數（sys.argv）

--pyargv "one two three"

該配置會將sys.argv 設爲('one','two','three')。

optimize

設置python爲最優化級別（要當心）

paste

use paste.deploy to load a WSGI app

使用paste.deploy 來加載一個WSGI程序。

uwsgi --paste config:/foo/development.ini

no-site [python plugin required]

不加載python的site.py模塊。

ping [ping plugin required]

工具性的選項。ping一個uwsgi服務器，若是ping成功，難麼進程就會退出，並返回0，不然返回一個大於0的值。

/usr/bin/uwsgi --ping 192.168.0.100:1717

將ping在192.168.0.100:1717的uWSGI服務器。

ping-timeout [ping plugin required]

設置ping的超時時間（默認是3秒）。ping的等待時間超過指定的秒數後就認爲該uWSGI實例已失效。

/usr/bin/uwsgi --ping 192.168.0.100:1717 --ping-timeout 10

將設置ping的超時時間爲10秒。

nagios

做nagios檢查。

fastrouter

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

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。