Trabalhadores do Apache mpm + wsgi Python / Django workers stuck

Question

Nosso servidor Apache + Django tem o problema de os funcionários ficarem presos. É um modelo de trabalho de mpm e, após algum tempo, cada processo que atende algumas dezenas de threads de trabalho tem todos os seus funcionários congelados:

# apache2ctl status
Apache Server Status for localhost

Server Version: Apache/2.2.14 (Ubuntu) mod_ssl/2.2.14 OpenSSL/0.9.8k mod_wsgi/
    2.8 Python/2.6.5
Server Built: Mar 8 2013 16:46:38

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Current Time: Friday, 05-Apr-2013 15:56:17 CEST
Restart Time: Thursday, 04-Apr-2013 11:23:23 CEST
Parent Server Generation: 11
Server uptime: 1 day 4 hours 32 minutes 53 seconds
Total accesses: 244313 - Total Traffic: 4.7 GB
CPU Usage: u181.45 s33.97 cu.62 cs0 - .21% CPU load
2.38 requests/sec - 47.9 kB/second - 20.2 kB/request
108 requests currently being processed, 42 idle workers

_K__K______KK_____W_________W________K_K__________..............
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW..............
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW..............
................................................................
................................................................
................................................................

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Ao fazer apache2ctl fullstatus , você pode ver que são exatamente dois PIDs que têm todos os trabalhadores em estado "em funcionamento". Atualmente, PID 822 e 5284. E esses processos não estão atendendo a nenhum pedido funcional. Além disso, eles só podem ser mortos com sinal 9 ( kill -9 )

A opção WSGIDaemonProcess cpu-time-limit=120/120 não nos ajudará por dois motivos: Apenas a versão 3.0 e superior do WSGI tem, além disso, os processos não estão consumindo CPU, portanto o tempo de CPU é baixo.

Nós experimentamos alguma lentidão com o servidor. Não é super lento, mas pode ser mais rápido (às vezes ele fica pendente de pedidos) e eu suspeito que esse problema esteja relacionado. De qualquer forma, não é para ser assim.

É um servidor Ubuntu 10.04 LTS com Apache 2.2.14 e libapache2-mod-wsgi 2.8-2ubuntu1. Os sites são exibidos como:

WSGIScriptAlias / /srv/http/bla/passenger_wsgi.py

Esta é a configuração do trabalhador:

<IfModule mpm_worker_module>
    StartServers          2
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      50
    MaxClients           200
    ServerLimit          6
    MaxRequestsPerChild  1000
</IfModule>

Alguma ideia do que é isto e como resolvê-lo? Ou, pelo menos, como definir algum kill automático nesses processos? Ulimit é difícil, porque eles não consomem muita CPU.

    

Answer 1

corrigi-lo algum tempo atrás, convertendo os sites para usar o modo daemon, em vez do modo incorporado, e colocando um proxy nginx na frente dele, o qual lida com toda a publicação de arquivos estáticos.

    

Answer 2

Você configurações MPM são um pouco quebradas por várias razões para começar. Sugiro que você assista a minha palestra da PyCon em:

• link

Quanto ao pendrço do seu servidor, você provavelmente tem um módulo de extensão de terceiros sendo usado que não é seguro usar de um subinterpretador. Você precisa forçar seu aplicativo a ser executado no interpretador principal. Veja:

• link

Para saber onde os processos estão suspensos, veja também os meios de obter rastreamentos de pilha, conforme descrito em:

• link
• link

Se for um impasse como esperado e não quiser apenas tentar usar o interpretador principal, provavelmente será necessário usar o gdb para obter rastros de pilha de onde ele está preso.

A abordagem de rastreio de pilha do Python funcionará se o problema é que seu código está bloqueando chamadas para serviços externos. Você também pode, talvez, ter uma ideia disso, examinando os descritores de arquivos abertos usando lsof ou ofiles.