Question

我在金字塔上有应用程序。我使用这些配置在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 errors.log：

*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可以杀死工人？我怎么知道原因？线路＆＃34; DAMN！工人2（pid：4247）去世了，...＆＃34;无话可说。

Answer 1

信号9表示它收到了SIGKILL。所以有些东西给你的工人发了一个杀戮内存杀手很可能决定杀死你的应用程序，因为它使用了太多的内存。尝试用过程监视器观察工作人员，看看它是否占用了大量内存。

Answer 2

尝试在uWSGI配置中添加harakiri-verbose = true选项。

Answer 3

我遇到了同样的问题，因为我更改了uwsgi.ini文件，将reload-on-rss设置的值从2048更改为4048，并且将harakiri更改为600。

如何找出uWSGI杀死工人的原因？

3 个答案: