web-dev-qa-db-ja.com

uWSGIが労働者を殺す理由を見つける方法は？

pyramidにアプリがあります。私はこれらの設定でuWSGIでそれを実行します：

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

そしてnginxconfig：

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]

そしてnginxerrors.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は労働者を殺すことができるのですか？そして、どうすればその理由を知ることができますか？ 「DAMN！worker 2（pid：4247）が死んだ、...」という行は何も言いません。

pythonnginxuwsgigevent
17
Greg Eremeev

シグナル9は、SIGKILLを受信したことを意味します。だから何かがあなたの労働者に殺害を送った。メモリ不足のキラーが、メモリを使いすぎたためにアプリを強制終了することを決定した可能性が比較的高くなります。プロセスモニターでワーカーを監視し、大量のメモリを使用していないかどうかを確認してください。

5
doxin