Scopri cosa sta effettivamente facendo il processo apache ad alto utilizzo della CPU?


18

Attualmente stiamo riscontrando alcuni problemi con il nostro server in cui, a intermittenza, sembra che si ottengano processi apache che si eseguono e funzionano, occupando il 100% della CPU.

Quando eseguiamo top, vediamo quanto segue:

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

Voglio provare a scoprire quale script (o qualunque cosa sia) sta causando questo, quindi ho provato:

 strace -p 20788

Ma questo non mostra alcun output (l'ho lasciato per circa 10 minuti e non mostra nulla). Da quanto ho capito, questo potrebbe significare che è bloccato in un ciclo infinito e non ci sono "chiamate di sistema" da mostrare.

C'è qualcos'altro che posso fare per mostrare cosa sta succedendo?

Grazie

Modifica - Hai dimenticato di menzionare, questo è un server live con poche centinaia di utenti contemporaneamente! Quindi non posso proprio provare a cambiare liberamente le opzioni di configurazione e riavviare apache.

Modifica 2 - Il backtrace (bt) di gdb non sembra essere molto utile quando PHP non è configurato con --enable-debug - mostra solo "execute ()", ma devo sapere cos'è lo script PHP effettivamente in esecuzione .. c'è un altro modo?

#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 ()

1
Apache supporta il riavvio "grazioso", quindi perché non dovresti?
poige

1
Penso che quando l'abbiamo provato in precedenza, non è stato possibile riavviarlo con grazia a causa dei processi "bloccati" di Apache ... anche se potrebbe essere sbagliato, è stato qualche tempo fa.
BT643,

Un altro trucco è eseguire un'altra istanza di apache su una porta diversa, reindirizzando nuove connessioni ad essa.
poige

Risposte:


9

Bene, nel caso ti senti coraggioso:

gdb -p 20788

quindi rilasciare btper vedere lo stack-frame, ad es

E a proposito, c'è anche ltraceda menzionare: provalo pure.

UPD. : bene, ok, dato che ora abbiamo un'idea che Apache stia davvero eseguendo qualcosa, perché non dovresti guardare mod_statusall'output - Extended ?


gdb non è installato :( dovrà aspettare fino a quando non torno a lavorare domani per vedere se posso installarlo senza causare problemi .. ltracenon ha mostrato alcun output.
BT643

Ho appena aggiunto i risultati del gdb bt nel post iniziale .. non mi dice davvero molto!
BT643,

Oh, felice di vedere che ho suggerito la giusta direzione. )
poige

@ BT643, vedi UPD.
poige

4
Mod_status realizzato era già abilitato per impostazione predefinita, era limitato all'accesso da 127.0.0.1. Ho appena effettuato l'accesso tramite SSH e ho reindirizzato l'output a un file curl domain.com/server-status > randomfile.html, quindi ho visualizzato il file. Si è scoperto che era un vecchio codice per sviluppatori bloccato in un ciclo (file PHP)! Tutti ordinati adesso. Grazie per l'aiuto :)
BT643

2

Un approccio molto semplice è quello di usare htop. È possibile ordinare per i processi con CPU elevata e quindi utilizzare

  • s per straceun processo
  • Per lsofvedere i file aperti di un processo
  • Da L a ltrace.

Ho scoperto che almeno una di quelle opzioni trova lo script che genera il carico e puoi ovviamente utilizzarlo su un server Web di produzione per eseguire il debug.


1

Puoi provare:

  • iotop (mostra I / O sul sistema)
  • netstat -t (mostra le connessioni)
  • Dai un'occhiata ai file di log di Apache e scopri cosa ha fatto il server per ultimo
  • imposta alcuni RLimits per il processo apache. Quando questi limiti vengono raggiunti, il processo verrà interrotto, dandoti alcune informazioni in più

0

Il comando dovrebbe funzionare a condizione che si effettui una richiesta HTTP che attivi quel PID.

Forse vuoi riconfigurare temporaneamente Apache con un solo processo figlio?


Tieni presente che solo un processo figlio significa che Apache può servire solo una singola richiesta e se quel singolo figlio è bloccato, Apache non sarà in grado di soddisfare alcuna richiesta.
Stefan Lasiewski,

Non posso farlo poiché è un server live con centinaia di utenti simultanei (l'hanno aggiunto
all'OP

0

Il PID di quell'istanza di Apache è basso, potrebbe essere il padre di tutto. Ciò spiegherebbe sicuramente l'elevato utilizzo della CPU (rimane intorno, altri vengono generati e richiamati in base al carico). Molto tempo accumulato per la CPU potrebbe significare che è in esecuzione da molto tempo. Nessun output da strace(1)significa solo che non ha fatto chiamate di sistema. Sì, potrebbe essere in un ciclo stretto, ma apache è essenzialmente I / O su rete, quindi penso che non stia facendo nulla di utile. Strano il 100% di una CPU, in ogni caso.


PID basso non significa necessariamente che è un vecchio processo. I PID hanno un valore massimo e vanno a capo in modo da poter creare nuovi processi utilizzando PID bassi.
austinian,

0

Prova questo:

1) Avvia un registro con data / ora, script PHP e PID utilizzando getmypid()

2) Quindi guarda il tuo server con top

3) Quando vedi che il processo di Apache sta salendo, cerca la stessa data / ora e PID nei tuoi registri. Dovresti essere in grado di trovare lo script problematico.


Questa è una soluzione interessante, ma vedo che occupa più risorse di quante ne valga la pena, dato che mod_statusfa abbastanza bene il suo lavoro.
Austinian,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.