web-dev-qa-db-fra.com

Découvrez ce que le processus Apache à forte utilisation du processeur fait réellement?

Nous rencontrons actuellement quelques problèmes avec notre serveur où, par intermittence, nous semblons obtenir des processus Apache qui s'exécutent et s'exécutent, occupant 100% du processeur.

Lors de l'exécution en haut, nous voyons ce qui suit:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20788 www-data  20   0  318m  18m 3984 R  100  0.0  40:29.21 /usr/sbin/Apache2 -k start
23523 www-data  20   0  319m  20m 4684 R  100  0.0   4:12.36 /usr/sbin/Apache2 -k start

Je veux essayer de savoir quel script (ou quoi que ce soit) est à l'origine de cela, alors j'ai essayé:

 strace -p 20788

Mais cela ne montre aucune sortie (je l'ai laissé pendant environ 10 minutes, et cela ne montre rien). D'après ma compréhension, cela pourrait signifier qu'il est coincé dans une boucle infinie, et qu'il n'y a aucun "appel système" à afficher.

Puis-je faire autre chose pour montrer ce qui se passe?

Merci

Edit - J'ai oublié de mentionner, ceci est un serveur en direct avec quelques centaines d'utilisateurs à la fois! Je ne peux donc pas vraiment essayer librement de changer les options de configuration et redémarrer Apache.

Edit 2 - La backtrace (bt) de gdb ne semble pas être très utile quand PHP n'est pas configuré avec --enable-debug - seulement affiche "execute ()", mais j'ai besoin de savoir ce que PHP est en cours d'exécution .. existe-t-il une autre manière?

#0  0x00007f6c143fb0c5 in ?? () from /usr/lib/Apache2/modules/libphp5.so
#1  0x00007f6c143b040b in execute () from /usr/lib/Apache2/modules/libphp5.so
#2  0x00007f6c1438b970 in zend_execute_scripts () from     /usr/lib/Apache2/modules/libphp5.so
#3  0x00007f6c14337fe3 in php_execute_script () from     /usr/lib/Apache2/modules/libphp5.so
#4  0x00007f6c1441ae7d in ?? () from /usr/lib/Apache2/modules/libphp5.so
#5  0x00007f6c18912508 in ap_run_handler ()
#6  0x00007f6c1891297e in ap_invoke_handler ()
#7  0x00007f6c18922570 in ap_process_request ()
#8  0x00007f6c1891f398 in ?? ()
#9  0x00007f6c18918fa8 in ap_run_process_connection ()
#10 0x00007f6c189271d0 in ?? ()
#11 0x00007f6c1892793a in ?? ()
#12 0x00007f6c189284e7 in ap_mpm_run ()
#13 0x00007f6c188fd4a4 in main ()
linuxapache-2.2ubuntu-12.04topstrace
19
BT643

Eh bien, au cas où vous vous sentiriez courageux:

gdb -p 20788

puis lancez bt pour voir le stack-frame, pour e. g.

Et BTW, il y a aussi ltrace à mentionner - essayez-le également.

UPD. : eh bien, ok, puisque maintenant nous avons une idée qu'Apache exécute vraiment quelque chose, pourquoi ne pas regarder mod_status sortie - étend un?

9
poige

Une approche très simple consiste à utiliser htop. Vous pouvez trier pour les processus CPU élevés, puis utiliser

  • s pour strace un processus
  • l pour lsof pour voir les fichiers ouverts d'un processus
  • L à ltrace.

J'ai trouvé qu'au moins une de ces options trouve le script qui génère la charge et vous pouvez bien sûr l'utiliser sur un serveur Web de production pour déboguer.

2
abuzze

Tu pourrais essayer:

  • iotop (montrant les E/S sur le système)
  • netstat -t (montrant les connexions)
  • Jetez un œil aux fichiers journaux d'Apache et découvrez ce que le serveur a fait en dernier
  • définir des RLimits pour le processus Apache. Lorsque ces limites seront atteintes, le processus sera tué, vous donnant ainsi plus d'informations
2
Kai Bojens

Votre commande devrait fonctionner à condition que vous fassiez une requête HTTP qui déclenche ce PID.

Vous souhaitez peut-être reconfigurer temporairement Apache avec un seul processus enfant?

0
Harry Slaughter

Le PID de cette instance Apache est faible, il pourrait être le père de tout le lot. Cela expliquerait certainement l'utilisation élevée du processeur (il reste, d'autres sont générés et rappelés en fonction de la charge). Une grande partie du temps CPU accumulé pourrait simplement signifier qu'il fonctionne depuis longtemps. Aucune sortie de strace(1) signifie simplement qu'il n'a fait aucun appel système. Oui, cela pourrait être dans une boucle étroite, mais Apache est essentiellement des E/S sur le net, donc je pense qu'il ne fait rien d'utile. Étrange à 100% d'un CPU, en tout cas.

0
vonbrand

Essaye ça:

1) Démarrez un journal avec la date/heure, PHP, et le PID en utilisant getmypid()

2) Surveillez ensuite votre serveur avec top

3) Lorsque vous voyez le processus Apache monter en puissance, recherchez la même date/heure et le même PID dans vos journaux. Vous devriez pouvoir trouver le script problématique.

0
phoenix