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

Gre*_*eev 17 python nginx gevent uwsgi

我在金字塔上有应用程序.我使用这些配置在uWSGI中运行它:

[uwsgi]
socket = mysite:8055
master = true
processes = 4
vacuum = true
lazy-apps = true
gevent = 100
Run Code Online (Sandbox Code Playgroud)

和nginx配置:

server {
    listen 8050;
    include uwsgi_params;

    location / {
        uwsgi_pass mysite:8055;
    }
}
Run Code Online (Sandbox Code Playgroud)

通常都很好,但有时uWSGI会杀死工人.我不明白为什么.

我在uWSGI日志中看到:

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

但在日志中没有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]
Run Code Online (Sandbox Code Playgroud)

和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:
Run Code Online (Sandbox Code Playgroud)

我认为这可以通过添加buffer-size = 32768来解决,但由于这个uWSGI杀死工作人员不太可能.

为什么uwsgi可以杀死工人?我怎么知道原因?行"DAMN!工人2(pid:4247)去世,......"没什么好说的.

dox*_*xin 8

信号 9 表示它收到了 SIGKILL。所以有些东西杀死了你的工人。内存不足杀手决定杀死您的应用程序的可能性相对较大,因为它使用了太多内存。尝试使用进程监视器观察工人,看看它是否使用了大量内存。

  • “尝试用进程监视器观察工人,看看它是否使用了大量内存”。我该怎么做呢? (8认同)