Uwsgi配置说明及优化

1.配置说明

# socket = 127.0.0.1:8000
# 项目目录
chdir = /root/centyuanblog/
# 项目中wsgi.py文件的目录
wsgi-file = /root/centyuanblog/centyaunblog/wsgi.py
#指定PID文件的位置，记录主进程的PID号
pidfile = uwsgi.pid
# 后台运行且配置日志文件
daemonize = uwsgi.log
# 多进程&多线程 enable-threads = true(不知道有没有用),去掉多线程，使用功能gevent
processes = 10
threads = 4
# logto=/root/sc_git/sc_api/logs/uwsgi.log
      # 1.定时器以天切割日志
      # touch-logreopen:是一个trigger，监听项目目录下的touchforlogrotat文件，如果文件发生变化，就重新打开日志
      # touch-logreopen 需要启动的时候加上 --log-reopen （reload会导致touch-reopen会失败，不会产生新的日志文件）
      touch-logreopen = /root/centyuanblog/logs/.touchforlogrotat
      # 2.以固定大小切割日志
      log-reopen=true
      log-maxsize = 50000000 #log-maxsize以固定的文件大小（单位KB），切割日志文件。 就是50M一个日志文件。
#使进程在后台运行，并将日志输出到指定的日志文件或者UDP服务器
daemonize = /root/centyuanblog/logs/uwsgi.log
# 服务停止时，自动移除unix socket和pid文件
vacuum = true
# 设置socket的监听队列大小,默认为 100 太小了。并发数 = procsses * threads * listen,最行之有效的方法
# Llinux系统内核对每个端口的监听队列进行了限制，默认是128,需要先修改系统的限制
# echo 500 > /proc/sys/net/core/somaxconn
# 或sysctl -w net.core.somaxconn=500
listen = 65535
# 进程回收:为每个工作进程设置请求数的上限。当处理的请求总数超过这个量，进程回收重启,防止内存泄露
max-requests = 5000          # 最大时间重启worker max-worker-lifetime = 30
# 允许主进程存在（enable master process）  使用 max-requests 必须采用这个选项
master = true
# 所有进程在 30s 没有响应后杀死
harakiri = 30
#当一个请求被harakiri杀掉会输出一条日志
harakiri-verbose = true
# uWsgi默认的buffersize为4096，如果请求数据超过这个量会报错。这里设置为64k
buffer-size = 65536
# 如果http请求体的大小超过指定的限制，打开http body缓冲，这里为64k
post-buffering = 65536
#开启内存使用情况报告
memory-report = true
#设置平滑的重启（直到处理完接收到的请求）的长等待时间(秒)
reload-mercy = 10
#设置工作进程使用虚拟内存超过多少MB就回收重启
reload-on-as = 1024
# 不记录请求信息的日志。只记录错误以及uWSGI内部消息到日志中。如果不开启这项，那么你的日志中会大量出现这种记录：
disable-logging = true
# 惊群问题SerializingAccept,在多进程下开启效果好 https://dev.admirable.pro/uwsgi-performance-tuning/
thunder-lock = true
# 指定虚拟环境
virtualenv = /data/venv/FZ
# home = %(base)/Env/%(project) # 设置项目虚拟环境,Docker部署时不需要
# 监控设置
stats = 127.0.0.1:9191  # 在指定的地址上，开启状态服务，uwsgi top 可以监控
# 自动重载，开发时非常方便
python-autoreload = 1
# 虚拟内存限制,通过使用POSIX/UNIX的setrlimit()函数来限制每个uWSGI进程的虚拟内存使用数,这个配置会限制uWSGI的进程占用虚拟内存# 不超过256M
limit-as = 256 
# .sock文件目录需与Nginx文件内的配置相同,和nginx关联,仅限于在同一主机上
socket = /root/centyuanblog/myblog_sock.sock
chmod-socket = 666
# uwsgi --ini uwsgi.ini # 启动
# uwsgi --reload uwsgi.pid # 重启
# uwsgi --stop uwsgi.pid # 关闭
# 支持gevent  在uwsgi中如果使用了gevent参数，就不能用threads参数了，不过，貌似仍可以在进程中创建线程(建议高并发使用gevent不用threads)
# uwsgi --gevent 100 --gevent-early-monkey-patch uwsgi.ini

uwsgi生成额外参数配置

uwsgi官方文档

2.实例配置

[uwsgi]
chdir = /data/ANS/
# http
http = :8000
# socket
# socket = /root/ANS/ans_sock.socko  #.sock文件目录需与Nginx文件内的配置相同,和nginx关联
# socket = 127.0.0.1:8000
chmod-socket = 666
vacuum = true
pidfile = /data/ANS/uwsgi.pid
daemonize = /data/ANS/logs/uwsgi.log
log-maxsize = 50000000
# worker进程回收
max-requests = 1000                  ; Restart workers after this many requests （1000 requests have been handled）
max-worker-lifetime = 3600           ; Restart workers after this many seconds （The worker has allocated 2 GB of memory）
reload-on-rss = 2048                 ; Restart workers after this much resident memory （1 hour has passed）
worker-reload-mercy = 60             ; How long to wait before forcefully killing workers

# 进程动态扩展(Dynamic Worker Scaling(cheaper))
这里有各种算法可用于确定在任何给定时刻应该有多少进程可用
busyness 算法:尝试始终有空闲的工作人员可用，这在预测意外的流量激增时很有用
cheaper-algo = busyness
processes = 500                      ; Maximum number of workers allowed
cheaper = 8                          ; Minimum number of workers allowed
cheaper-initial = 16                 ; Workers created at startup
cheaper-overload = 1                 ; Length of a cycle in seconds
cheaper-step = 16                    ; How many workers to spawn at a time

cheaper-busyness-multiplier = 30     ; How many cycles to wait before killing workers
cheaper-busyness-min = 20            ; Below this threshold, kill workers (if stable for multiplier cycles)
cheaper-busyness-max = 70            ; Above this threshold, spawn new workers
cheaper-busyness-backlog-alert = 16  ; Spawn emergency workers if more than this many requests are waiting in the queue
cheaper-busyness-backlog-step = 2    ; How many emergegency workers to create if there are too many requests in the queue

--enable-threads：UWSGI默认情况下，没有开启多线程的支持，由于探针基于多线程模式，所以必须开启此模式，否则探针无法正常启动。如果UWSGI使用了选项--threads，将自动开启选项--enable-threads。

--single-interpreter：默认情况下 UWSGI为了隔离应用环境，以便运行多个应用，在启动的时候会启动子进程来运行某个应用，而不是在主进程中执行。为了更好的适应探针环境请开启这个选项，开启后不会有其他任何的副作用，它也是安全而有效的方式。

--lazy：该选项开启后，UWSGI将会在 worker进程中加载 app，而不是在master中加载 app。这样做完全不受影响，因为UWSGI在工作时，master是不工作的，它只负责调度。

3.uWSGI和Nginx之间有3种通信方式

# 1. unix socket 仅限于同一主机:优先使用本地机器的unix socket进行通信，这样速度更快
socket = /root/project/my_sock.sock
location / {
include /etc/nginx/uwsgi_params;
uwsgi_pass unix : /run/uwsgi/project.sock;
}
# 2. Tcp socket
socket = 0.0.0.0:8000 或socket=:8000
location / {
include /etc/nginx/uwsgi_params;
uwsgi_pass uWSGI_SERVER_IP : 8000;
}
# 3. http
http = 0.0.0.0:8000
location / {
# 注意：proxy_pass后面http必不可少哦！
proxy_pass http://uWSGI_SERVER_IP:8000;
}

4. 部署方案对比

WSGI UWSGI 多进程，多线程，同步 所有 WSGI协议框架

WSGI Gunicorn 多进程，io异步 所有 WSGI协议框架

WSGI Gevent 单进程，io异步 所有 WSGI协议框架

非WSGI Tornado 单进程，网络异步 WSGI App不建议/Tornado

参考[部署方案建议][https://wukongdoc.tingyun.com/apm/deploy/Python/proposal.html]