Travailleur Apache mpm + wsgi Travailleurs Python / Django bloqués

Notre serveur Apache + Django a le problème que les travailleurs restent bloqués. C'est un modèle de travail de mpm, et après un certain temps, chaque processus qui dessert une douzaine de threads de travail a tous ses travailleurs gelés:

# 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 

Lorsque vous effectuez apache2ctl fullstatus , vous pouvez voir que c'est exactement deux PID qui ont tous leurs travailleurs en état de fonctionnement. Actuellement, PID 822 et 5284. Et ces processus ne servent aucune demande fonctionnelle. En outre, ils ne peuvent être tués qu'avec le signal 9 ( kill -9 )

L'option WSGIDaemonProcess cpu-time-limit=120/120 ne nous aidera pas pour deux raisons: seuls WSGI version 3.0 et versions supérieures l'ont, plus, les processus ne consomment pas de CPU, de sorte que leur temps CPU est faible.

Nous connaissons une lenteur avec le serveur. Ce n'est pas très lent, mais il peut être plus rapide (parfois il se bloque sur les demandes) et je soupçonne que ce problème est lié. En tout cas, ce n'est pas censé être comme ça.

C'est un serveur Ubuntu 10.04 LTS avec Apache 2.2.14 et libapache2-mod-wsgi 2.8-2ubuntu1. Les sites sont servis comme suit:

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

C'est la configuration du travailleur:

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

Une idée de ce que c'est et comment le résoudre? Ou, au moins, comment définir un tueur automatique sur ces processus? Ulimit est difficile, car ils ne consomment pas beaucoup de CPU.

Les paramètres MPM sont un peu brisés pour diverses raisons pour un démarrage. Suggérez-vous de regarder mon exposé de PyCon à:

En ce qui concerne votre serveur suspendu, vous avez probablement un module d'extension tiers utilisé qui n'est pas sûr d'utiliser un sous-interprète. Vous devez forcer votre application à s'exécuter dans l'interprète principal. Voir:

Pour savoir où les processus sont suspendus, consultez également les moyens d'obtenir des traces de pile comme décrit dans:

Si c'est une impasse comme prévu et que vous ne souhaitez pas simplement essayer d'utiliser l'interprète principal, il faudra probablement utiliser gdb pour obtenir des traces de pile où il est bloqué.

L'approche des traces de pile Python fonctionnera si le problème est que votre code bloque les appels vers des services externes. Vous pouvez également avoir une idée de cela en regardant les descripteurs de fichiers ouverts en utilisant lsof ou ofiles.

Je l'ai réparé il y a quelque temps en convertissant les sites pour utiliser le mode Daemon, au lieu du mode intégré, et en mettant un proxy nginx devant lui, qui gère tout le service de fichiers statiques.