Apache se bloque à la "demande de lecture", et PID occupé 100% CPU

Récemment, dans une certaine mesure coïncidant avec certaines mises à jour des serveurs (Bien qu'il y ait eu plusieurs changements qui ont été faits), Apache Il a commencé à se terminer par le fait que certains de ses processus sont bloqués dans l'état "Read Demande". Chaque PID, qui tombe dans cette affection prend 100% CPU et a très peu, ce qui correspond à lui et à un autre processus dépendant (selon lsof) - Certains ont des connexions ouvertes TCP / IP, Certains ont attendu, certains seulement écoutent www.

Le schéma est comme suit:

redémarrage apache

attends un peu (minutes)

Obtenez le processus de zombies "Demander la lecture", le processeur commence à travailler

Plus de zombies viennent, tout ne correspond pas à quelque chose d'évident

Le chargement du processeur atteint 15-40 Selon quand je l'ai remarqué.

GOTO 1

Le cycle entier dure de 30 Minutes 4 heures, en fonction de ma capacité à effectuer une étape de manière opportune 1.

server-status Donne moi:

R_.__.K._K.._._...._........W...................................
................................................................
................................................................
................................................................

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

Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
0-0 24363 0/1/7 R 0.46 447 844 0.0 0.00 0.26 ? ? ..reading..
[followed by a bunch of entirely normal requests]

Bien sûr, des informations clés qui m'aideraient à déboguer cela est manquante dans la barre d'état du serveur.

Je ne pouvais pas le suivre à quelque chose de concret. J'ai essayé lsof, netstat, Regarder via des magazines (Bien qu'il y ait des tonnes de magazines qui doivent être visionnées. Rien d'évident trouvé). Il n'y a pas de sauts dans le trafic réseau et le serveur sert activement beaucoup de sites Web aléatoires, afin que les composés entrants sont donc difficiles.

Initialement, il a commencé avec une installation obsolète Lenny, Par conséquent, j'ai commencé une mise à jour partielle du paquet à Squeeze. Jusqu'à présent, aucune mises à jour n'a conduit au fait qu'il a disparu (Bien que, heureusement, je reçois de bons logiciels frais!).

En plus du début
http://httpd.apache.org/dev/debugging.html
, Y a-t-il autre chose qui peut être fait pour essayer de trouver la source du problème?

Des détails:

Debian Lenny / Squeeze (fondamentalement Lenny. Certains composants sont mis à jour pour Squeeze), travaille dans Linux 2.6.32-5-xen-amd64 sur l'hôte Debian Squeeze Xen.

Forme préliminaire Apache2 MPM (2.2.16-6 + squeeze7)

Modules: libapache2-mod-fastcgi, libapache2-mod-perl2, libapache2-mod-php5, libapache2-mod-python, libapache2-mod-scgi, libapache2-mod-wsgi, libapache2-modxslt, libapache2-svn
Invité:

Blanche

Confirmation de:

J'ai le même problème sur mon serveur en cours d'exécution CentOS 6.2. Je soupçonne qu'il est en quelque sorte connecté à un redémarrage en douceur dans le cadre de la rotation hebdomadaire des journaux. Quand j'ai mis en place le processus httpd, Qui occupe 100% Cycle de la CPU, il est amarré sur la lecture des lignes vides du descripteur de canal (STDIN?). Donc, je suppose que le problème principal est que read () doit bloquer et ne pas renvoyer zéro tout le temps causant 100% Télécharger la CPU.

Pour répondre aux questions, connectez-vous ou registre