uwsgi 注意事项

http 、http-socket、socket 的区别

• http 和 http-socket 选项是完全不同的。第一个生成一个额外的进程，转发请求到一系列的worker (将它想象为一种形式的盾牌，与apache或者nginx同级)，而第二个设置worker为原生使用http协议。
• socket 模式：接收的是uwsgi 协议的数据包，前台需配合nginx 做负载均衡转发过来
• http-socket 模式： 接收的是http 协议的数据包，前台可配合nginx 转发
• http 模式： 额外启动一个http 进程（类似nginx）转发 uwsgi 协议的数据包到worker,http 模式也可只当成nginx 使用

• 当使用 http 模式启动时，worker 进程会随机监听一个端口， 当curl 测试返回curl: (52) Empty reply from server， 通常可能是iptables 防火墙的原因，导致请求无法到达workerj进程；

  uwsgi 加载app 失败，Internel Error

  因为wsgi 的app 加载的时候依赖中间件，当中间件not ready 时，app 加载失败， uwsgi 仍然运行中，但部分或全部worker 不能访问， 解决办法；

  • 增加参数 lazy-apps、need-app 参数，当有一个worker 加载失败时，会kill all workers, 整个uwsgi 退出
  • 业务应用try catch , 碰到异常，直接os._exit(1), master 会主动拉起；
  • lazy-apps/lazy比较，lazy已经不建议使用

编译的uwsgi 打包到新

环境，无法找到python 解释器；

• 问题

  Could not find platform independent libraries 
  Could not find platform dependent libraries 
  Consider setting $PYTHONHOME to [:]
  Fatal Python error: initfsencoding: Unable to get the locale encoding
  ModuleNotFoundError: No module named 'encodings'

• 2种解决办法：

  1. python 安装到，编译uwsgi环境时python的路径
  2. 指定PYTHONHOME 环境变量，export PYTHONHOME=python 安装路径， PYTHONHOME 下一定必须有 bin/ 、lib/

一定要启动master manager, 来管理子进程worker, --master

如何使用keep-alive

1. 使用http 代理模式， keep-alive = 100(int, default 4), http-auto-chunked = true; add-header = Connection: Keep-Alive
2. 如果使用Http11-socket 模式，默认开启keep-alive, 但timeout=4, 且不能修改；

=============
参考链接： https://uwsgi-docs-zh.readthe...

[uwsgi]
master = true
callable = app
; socket = 0.0.0.0:8082
; http = 0.0.0.0:8082
chdir = $(PATH)
wsgi-file = modules/webserver/app.py
; logto = /logs/%n.log
; processes = 8
threads = 1
lazy = true
log-maxsize = 102400000
; enable-threads = true
; pidfile = $(ST_DATA_PATH)/%n.pid

; pod 内查看 process 监控: uwsgitop 127.0.0.1:8300
stats = 0.0.0.0:8300
; 不记录uwsgi的request日志，只记录错误日志        
disable-logging = true
; 等同于 lazy = true. 在每个worker 里都重新加载app，而不是仅在 master,可能会消耗更多的内存,但是能做到优雅重启，服务不停机
lazy-apps = true
; 如果没有app 加载，则退出
need-app = true
; 超时还没有收到响应，客户端直接端口连接，但是服务器还在计算
; http-timeout = 2
; 等同于 http-timeout
; socket-timeout = 2
; 服务器超过 3s 后就直接不计算了
harakiri = 2
; 当一个请求是“harakiri”杀死的,会记录信息到uwsgi日志里
harakiri-verbose = true

; 多线程的话，uwsgi会自动开启 thunder-lock，但是多进程的话需要手动开启。 
; 解决惊群问题：多个进程或者线程在等待同一个事件，当事件发生时，所有线程和进程都会被内核唤醒。
; 唤醒后通常只有一个进程获得了该事件并进行处理，其他进程发现获取事件失败后又继续进入了等待状态。
; 监听同一个事件的进程数越多，争用 CPU 的情况越严重（尽管实际上只有一个进程能成功获得事件并进行处理），造成了严重的上下文切换成本。实验发现，能够将请求平均分配到多个worker
thunder-lock = true

; spare2: 适用于更快增长worker数，并且较慢降低 worker 数
cheaper-algo = spare2
; 启用cheaper模式, 代表最少保持 的worker 数量, 要小于 processes
cheaper = 4
; 初次启动时的数量
cheaper-initial = 8
; 每次需要增加的worker数
cheaper-step = 2
; 调整周期，单位：秒
idle = 30
; 上限尽量高点，以应对意料之外的高并发
processes = 25
# 当worker 进程常驻物理内存超过2048MB 时，进行重启， evil-reload-on-rss 是暴力重启，不等待当前请求处理完；
reload-on-rss = 2048
# uwsgitop 能显示内存情况
memory-report = true