重新启动时uWSGI停机 [英] uWSGI downtime when restart

问题描述

每次更新代码时，每次重新启动服务器时，uwsgi都会出现问题.

I have a problem with uwsgi everytime I restart the server when I have a code updates.

1. 当我使用"sudo重新启动记帐"重新启动uwsgi时，停止实例和启动实例之间存在很小的差距，导致停机并停止所有当前请求.

1. When I restart the uwsgi using "sudo restart accounting", there's a small gap between stop and start instance that results to downtime and stops all the current request.

当我尝试"sudo reload accounting"时，它可以工作，但是我的内存却增加了(两倍).当我运行命令"ps aux | grep accounting"时，它显示我有10个正在运行的进程(accounting.ini)而不是5个，并且当内存达到极限时，它将冻结我的服务器.

When I try "sudo reload accounting", it works but my memory goes up (double). When I run the command "ps aux | grep accounting", it shows that I have 10 running processes (accounting.ini) instead of 5 and it freezes up my server when the memory hits the limit.

accounting.ini

我在跑步

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

推荐答案

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

This is how uwsgi does graceful reload. Keeps old processes until requests are served and creates new ones that will take over incoming requests.

阅读可能出错的地方

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

Do not forget, your workers/threads that are still running requests could block the reload (for various reasons) for more seconds than your proxy server could tolerate.

还有这个

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

Another important step of graceful reload is to avoid destroying workers/threads that are still managing requests. Obviously requests could be stuck, so you should have a timeout for running workers (in uWSGI it is called the "worker’s mercy" and it has a default value of 60 seconds).

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

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

Default value is to wait 60 seconds, just lower it to something that your server can handle.

告诉我它是否有效.

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

This is another try to fix your issue. As you mentioned your uwsgi workers are restarting in a manner described below:

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

1. send SIGHUP signal to the master
2. Wait for running workers.
3. Close all of the file descriptors except the ones mapped to sockets.
4. Call exec() on itself.

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

One of the cons of this kind of reload might be stuck workers. Additionaly you report that your server crashes when uwsgi maintains 10 proceses (5 old and 5 new ones).

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

I propose trying chain reload. DIrect quote from documentation explains this kind of reload best:

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

When triggered, it will restart one worker at time, and the following worker is not reloaded until the previous one is ready to accept new requests.

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

It means that you will not have 10 processes on your server but only 5.

应该可以使用的配置:

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

一些关于链装填的资源以及其他种类的资源位于以下链接中:

Some resources on chain reload and other kinds are in links below:

链重新加载uwsgi文档

uWSGI优美部署Python代码

这篇关于重新启动时uWSGI停机的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！