CPU bloccata al 99% per alcune ore: capire i registri


8

estratto da syslog:

CRON[pid]: (user) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -
execdir fuser -s {} 2>/dev/null \; -delete)

La mia CPU è rimasta bloccata al 99% per alcune ore ormai, e presumo sia per questo. Qualcuno capirà di cosa si tratta, come è iniziato e come fermarlo?

EDIT: ho provato top -n1e vedo questo in cambio più volte:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND  
PID user      20   0     0    0    0 Z 99.9  0.0   0:00.00 fuser <defunct>

questa riga si ripete circa 8 volte.

EDIT2:

uname-a:

user SMP Tue Feb 14 13:27:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux`
lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 11.10
Release:    11.10
Codename:   code

EDIT 3:

Dopo il riavvio, il sistema è tornato allo stesso 99% cpu usagee allo stesso top -n1risultato.


3
C'è un bug in quel comando. L'output stderr del fusore viene inviato a / dev / null, come previsto. Ma così è l'output stderr di find, che probabilmente non lo era. (Poiché -execdir in realtà non avvia il comando tramite la shell, quindi 2> / dev / null viene elaborato dalla shell direttamente invocata da cron). Tuttavia, sebbene ciò possa nascondere sintomi rilevanti, il posizionamento di 2> / dev / null non è la causa dell'utilizzo della CPU.
James Youngman,

3
Questo è molto strano: un processo zombie non dovrebbe usare il tempo della CPU (non ha nemmeno il codice da eseguire). Hai un bug negli strumenti di reporting dei processi o nel tuo kernel. Che sistema operativo è questo (versione, kernel, ecc.)? C'è qualche virtualizzazione? Qual è l'output di uname -ae lsb_release -a?
Gilles 'SO- smetti di essere malvagio' il

1
Il fusercomando ha probabilmente una vita molto breve. Trascorre il suo tempo utilizzando il tempo della CPU (tempo di sistema, non ora dell'utente) generando / proc che i dati che (banalmente) consuma. Ogni istanza di fuserprobabilmente termina molto rapidamente. Ma probabilmente viene eseguito molte volte poiché, suppongo, ci sono molti file di sessione. Il dato del 99,9% probabilmente significa solo che quell'istanza di fuserCPU usata intensivamente prima di morire. findprobabilmente non è molto aggressivo nel raccogliere i bambini; probabilmente chiamerà di waitpidnuovo solo quando si esce da una directory o si esegue di fusernuovo.
James Youngman,

uname-a: user SMP Tue Feb 14 13:27:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux lsb_release -a: non sono disponibili moduli LSB. ID distributore: Ubuntu Descrizione: Ubuntu 11.10 Rilascio: 11.10 Nome in codice: codice
Jack

Oops, correzione: -execdir ... \;l'attesa dovrebbe essere immediata, poiché il codice di ritorno è necessario come risultato del predicato (stavo mescolando questo con il -execdir ...+quale ritorna sempre vero, penso).
James Youngman,

Risposte:


5

Questo è un lavoro cron che pulisce i vecchi file di sessione da / var / lib / php5 /. Se si blocca sul 99%, dovresti forse controllare la cartella di destinazione (/ var / lib / php5 /) per una quantità eccessiva di file o forse anche la corruzione del file system.

Il processo è avviato da crontab. Vedi gli elenchi crontab (descritti qui ). Puoi uccidere il processo e rimuoverlo da crontab, ma è più probabile che tu abbia un problema sottostante come una quantità eccessiva di file che deve essere riparato.


1
Se finisci con più processi di pulizia in esecuzione, potrebbero interferire tra loro generando blocchi nella directory quando eliminano i file. Prova a rimuoverlo temporaneamente dal crontab fino a quando il carico non viene cancellato. Quindi aggiungilo con un intervallo più lungo tra le esecuzioni. Potrebbe essere necessario spostarlo in uno script con un meccanismo di blocco per assicurarsi che sia in esecuzione solo un'istanza. Per ora, uccidi tutte le istanze multiple del comando.
BillThor,

2

Hai trovato la risposta qui: http://www.flynsarmy.com/2011/11/fuser-using-100-cpu-in-ubuntu-11-10/

in /etc/cron.d/php5 on Ubuntu 11.10:

Sostituire
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] &amp;&amp; [ -d /var/lib/php5 ] &amp;&amp; find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2&gt;/dev/null \; -delete

Con
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] &amp;&amp; [ -d /var/lib/php5 ] &amp;&amp; find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete


Questo ha funzionato, il problema sembra essere risolto.
Jack,
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.