uwsgi.ini 参数介绍

[uwsgi]
wsgi-file=app.py  # 应用的主文件
callable=app  # 应用中的 flask 实例
chdir=/opt/app  # chdir 到给定目录
env= XXX=XXX  # 额外的环境变量

# 以下三者任选其一
http=0.0.0.0:5000  # 如果直接暴露 uwsgi 的话用这个
http-socekt=0.0.0.0:5001  # 如果用 nginx 反向代理的话，用这个
socket=:3031  # 在 3031 使用 uwsgi 协议，nginx 中使用 uwsgi_pass 更高效

chmod-socket = 664

pidfile=xxx  # pid 文件路径
venv=xxx  # 虚拟环境路径
logto = /var/log/www.log

# 并发设置
workers = 2  # 一般为 CPU 核数 * 2
threads = 2  # 线程比进程开销更小一点。如果没有使用 threads 那么 thread 直接不工作的，必须使用 enable_threads。
max-requests = 100000  # 处理过多少个请求后重启进程，目的是防止内存泄露
master = true  # 使用 max-requests 必须采用这个选项
listen = 65536  # 每个进程排队的请求数量，默认为 100 太小了。并发数 = procsses * threads * listen
buffer-size = 65536  # header 的 buffer 大小，默认是 4 k
thunder-lock = true  # 避免惊群效应
uid=www-data
gid=www-data
harakiri=30  # 所有进程在 30s 没有响应后傻屌
log-slow=3000  # 记录满于 3000 毫秒的请求
# lazy-apps  # 不使用 prefork，而是在需要时才启动进程

# 监控设置
stats = 127.0.0.1:9191  # 可以使用 uwsgi top 监控
python-autoreload=1  # 自动重载，开发时非常方便

# 静态文件
check-static = /var/static  # 尝试从该目录下加载静态文件
static-map = /static=/var/static  # 把对应目录映射
route = /static/(.*)\.png static:/var/www/images/pngs/$1/highres.png  # 使用高级路由模式
offload-threads = 10  # 让 uwsgi 启动额外的进程处理

die-on-term = true

processes = 4           # 多个work进程
enable-threads = true   # 允许启动多线程

　Demo2

[uwsgi] DEMO2
wsgi-file = main.py # 主要運行的 py 檔案
callable = app # flask 實例化後的命名
chdir = /opt/app # chdir 指定目錄位置
env = XXX=XXX # 新增環境變數

# 選擇協議方式，三選一即可
http = 0.0.0.0:5000 # 此方法外部也可以使用 5000 ports 連線
http-socekt = 0.0.0.0:5001
socket = :3031

chmod-socket = 660

pidfile = xxx # pid 文件位置
venv = xxx # 虛擬環境位置
logto = /var/log/www.log

workers = 4 # 一般為 CPU 數 * 2
threads = 2
enable-threads = true

max-requests = 100000
master = true # 開啟一個主進程，管理其他進程

buffer-size = 65535 # header 的 buffer 大小，默認是 4096 字節，最大值是 65535 字節

vacuum = true # 當服務器退出的時候自動清理環境，刪除unix socket文件和pid文件

# 建議不要以 root 權限運行 uWSGI，這邊設定為 www-data
uid=www-data
gid=www-data


# 靜態文件
check-static = /var/static

Preforking VS lazy-apps VS lazy

这是uWSGI项目具有争议的选择之一。

默认情况下，uWSGI在第一个进程中加载整个应用，然后在加载完应用之后，会多次 fork() 自己。这是常见的Unix模式，它可能会大大减少应用的内存使用，允许很多好玩的技巧，而在一些语言上，可能会让带给你很多烦恼。

尽管它的名声如此，但是uWSGI是作为一个Perl应用服务器 (它不叫做 uWSGI，并且它也并不开源) 诞生的，而在Perl的世界里，preforking一般是一种受到祝福的方式。

然而，对于许多其他的语言、平台和框架来说，这并不是真的，因此，在开始处理uWSGI之前，你应该选择在你的栈中如何管理 fork() 。

而从“优雅重载”的角度来看，preforking极大的提高了速度：只加载你的应用一次，而生成额外的worker将会非常快。避免栈中的每个worker都访问磁盘会降低启动时间，特别是对于那些花费大量时间访问磁盘以查找模块的框架或者语言。

不幸的是，每当你的修改代码时，preforking方法迫使你重载整个栈，而不是只重载worker。

除此之外，你的应用可能需要preforking，或者由于其开发的方式，可能完全因其崩溃。

取而代之的是，lazy-apps模式会每个worker加载你的应用一次。它将需要大约O(n)次加载 (其中，n是worker数)，非常有可能会消耗更多内存，但会运行在一个更加一致干净的环境中。

记住：lazy-apps与lazy不同，前者只是指示 uWSGI对于每个worker加载应用一次，而后者更具侵略性些 (一般不提倡)，因为它改变了大量的内部默认行为。