uWSGI重启时的停机时间

Question

每当我有代码更新时，每次重启服务器时都会遇到uwsgi问题。

1. 当我使用“sudo restart accounting”重新启动uwsgi时，停止和启动实例之间的间隙会导致停机并停止所有当前请求。

2. 当我尝试“sudo reload accounting”时，它可以工作，但我的记忆力上升（双倍）。当我运行命令“ps aux | grep accounting”时，它显示我有10个正在运行的进程（accounting.ini）而不是5，当内存达到限制时它会冻结我的服务器。

accounting.ini



我正在运行

• Ubuntu 14.04
• Django 1.9
• nginx 1.4.6
• uwsgi 2.0.12

Answer 1

这是uwsgi正常重新加载的方式。保留旧的流程，直到请求得到处理为止，并创建新的流程来接管传入的请求。

阅读Things that could go wrong

  

不要忘记，您的工作线程/线程仍在运行请求   （由于各种原因）可能会阻止重新加载超过几秒钟   您的代理服务器可以容忍。

还有这个

  

优雅重新加载的另一个重要步骤是避免破坏   仍在管理请求的worker /线程。显然要求   可能会卡住，所以您应该让正在运行的工人超时（在   uWSGI，它被称为“工人的怜悯”，其默认值为   60秒）。

所以我建议尝试worker-reload-mercy

默认值为等待60秒，将其降低到服务器可以处理的水平。

告诉我它是否有效。

---

Uwsgi链重装

这是另一种尝试解决您的问题的方法。正如您提到的，您的uwsgi工作者正在以以下所述的方式重新启动：

1. 向主设备发送SIGHUP信号
2. 等待正在运行的工人。
3. 关闭除映射到套接字的文件描述符以外的所有文件描述符。
4. 自行调用exec（）。

这种重新加载的弊端之一可能是卡住的工人。 另外，您报告uwsgi维护10个进程（5个旧进程和5个新进程）时服务器崩溃。

我建议尝试重新加载链。文档中的直接引用最能说明这种重新加载的方式：

  

被触发后，它将一次重新启动一个工作线程，并且直到上一个工作线程准备好接受新请求时，才会重新加载下一个工作线程。

这意味着您的服务器上将没有10个进程，而只有5个进程。

应该正常工作的配置：

# your .ini file
lazy-apps = true
touch-chain-reload = /path/to/reloadFile

一些有关链式装载和其他种类的资源位于下面的链接中：

Chain reloading uwsgi docs

uWSGI graceful Python code deploy