如何找出uWSGI为何杀死工作进程？

Question

我有一个用Pyramid做的应用程序。我在uWSGI上运行它，配置如下：

[uwsgi]
socket = mysite:8055
master = true
processes = 4
vacuum = true
lazy-apps = true
gevent = 100

还有nginx的配置：

server {
    listen 8050;
    include uwsgi_params;

    location / {
        uwsgi_pass mysite:8055;
    }
}

通常一切都很好，但有时候uWSGI会杀掉工作进程。我也不知道为什么。

我在uWSGI的日志中看到：

DAMN ! worker 2 (pid: 4247) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 2 (new pid: 4457)

但是日志里没有Python的异常信息。

有时候我在uWSGI的日志中看到：

invalid request block size: 11484 (max 4096)...skip
[uwsgi-http key: my site:8050 client_addr: 127.0.0.1 client_port: 63367] hr_instance_read(): Connection reset by peer [plugins/http/http.c line 614]

还有nginx的错误日志：

*13388 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1,
*13955 recv() failed (104: Connection reset by peer) while reading response header from upstream, client:

我觉得可以通过添加buffer-size=32768来解决这个问题，但这不太可能是导致uWSGI杀掉工作进程的原因。

为什么uWSGI会杀掉工作进程？我怎么才能知道原因呢？那句“DAMN ! worker 2 (pid: 4247) died, ...”并没有提供任何信息。

Answer 1

对我来说，问题是我没有填写 app.config["SERVER_NAME"] = "x" 这个配置。

Answer 2

我也遇到过同样的问题。对我来说，修改uwsgi.ini文件，把reload-on-rss的值从2048改成4048，还有把harakiri改成600，解决了这个问题。

Answer 3

试着在uWSGI的配置文件里加上 harakiri-verbose = true 这个选项。

Answer 4

信号9表示收到了一个叫做SIGKILL的指令。这意味着有东西发出了一个“终止”信号给你的工作程序。很有可能是因为你的应用程序占用了太多内存，所以系统的“内存不足杀手”决定把它杀掉。你可以试着用进程监视工具观察一下这些工作程序，看看它们是否使用了很多内存。