Come trovare la causa del crescente carico del server

12

Sto riscontrando problemi di caricamento con il mio server e anche se sono un amministratore Linux piuttosto esperto, non ho più idee.

Il problema è un carico lento ma costante sul server senza alcuna causa apparente.

Il server è un processore dual core AMD Athlon (tm) 64 X2 6000+ con 6 GB di RAM. Funziona su Debian Stable con Linux gir 2.6.26-2-amd64 # 1 SMP mer 19 ago 22:33:18 UTC 2009 x86_64 GNU / Linux.

Il server esegue fondamentalmente Lighttpd, diversi processi PHP FastCGI e un database MySQL. Attività tipiche del server web.

La CPU non è mai completamente utilizzata e la memoria viene utilizzata principalmente per buffer e cache, il che va bene. Ho provato a riavviare i vari servizi per vedere se uno di loro avrebbe ridotto di nuovo il carico, ma senza fortuna.

Ecco la grafica che mostra il carico, la CPU e IOStat:

Quindi, la domanda è: cosa potrebbe causare un carico lento ma sempre crescente? E come faccio a sapere cosa è responsabile?

Aggiornamento: ho dimenticato di menzionare, quando riavvio il server, il carico scenderà da 0,3 a 0,6 e ricomincerà a risalire lentamente nelle prossime settimane.

linux

— Andreas Gohr
fonte

1

Le immagini che hai pubblicato non esistono più. Sentiti libero di ricaricarli se hai ancora delle copie.

— Michael Hampton

6

Ogni processo di zombi aggiunge 1,0 al carico. Potresti vedere un accumulo di zombi.

Sì. Controllare il grafico " Numero di processi ".

— Teddy

Se era corretto, la digitazione for N in {1..100} ; do sleep 60 & done ; exec sleep 500dovrebbe essere sufficiente per causare un carico elevato. Ma non lo fa. Questo comando produce 100 zombi, ma il carico sul mio computer è rimasto al di sotto dell'1.

— Kasperd

5

Ho trovato un suggerimento eccellente in risposta a una domanda diversa .

La ricerca di processi nello stato 'D' mostra quattro processi PHP che sembrano bloccarsi per un po 'corrispondenti ai "passaggi" nella curva di carico:

#> ps aux | awk '$8 ~ /D/  { print $0 }'
wiki      6651  0.0  0.0      0     0 ?        D    Oct04   0:41 [php-cgi]
bugs      6731  0.0  0.0      0     0 ?        D    Oct27   0:14 [php-cgi]
manpages  7536  0.0  0.0      0     0 ?        D    Oct30   0:21 [php5-cgi]
wiki     23847  0.0  0.0      0     0 ?        D    Oct06   1:32 [php-cgi]

Quindi questi sembrano essere il problema. Ora ho bisogno di scoprire mentre quei processi si bloccano e come risolverlo. Grazie a tutti.

— Andreas Gohr
fonte

Questa risposta ha risolto il mio problema. Il carico aumentò da 0,5 a 350 e continuò a salire. Era dovuto ai processi di zombi che cercavano di leggere una cartella remota eliminata.

— Philippe Delteil,

2

La mia ipotesi è che il server sia IO affamato, forse dovresti aggiungere le statistiche iotop ai grafici

Mi chiedo se puoi avere un'attività io per applicazione che è anche un fattore per il carico del server

http://rt.wiki.kernel.org/index.php/I/Otop_utility

l'altro strumento è dstat

— Mariuz
fonte

Ho aggiunto anche grafica per IOStat. L'IO del disco non aumenta come il carico. È quello a cui miravi?

— Andreas Gohr,

Oh e dstat sembra utile. Devo leggere qualcosa in più al riguardo.

— Andreas Gohr,

2

Se fosse I / O, vedrebbe lo iowait (rosa) sui grafici della CPU.

— 3molo
fonte

0

Questo tipo di problemi veniva spesso dal disco rigido che non è abbastanza veloce per servire i dati richiesti dal database MySQL e dal server HTTP. Dovresti guardare il comando iostat

IO mi sembra normale. E non spiegherebbe perché il carico sta lentamente aumentando.

— Andreas Gohr,

-1

In generale, in realtà non è male avere un carico elevato del server; significa che non sei seduto inattivo e fai meno di quanto potresti altrimenti. 80% -90% di carico della capacità totale (con un po 'di spazio "scoppiato") è ciò che di solito è ricercato. Consiglio di controllare l'output di mpstat e vmstat. In particolare, i primi 2 numeri di vmstat possono darti informazioni più significative su come "esegui il backup" in termini di processi nella coda di esecuzione. L'ultima colonna ("wa") dell'output di vmstat può dirti se e per quanto tempo stai aspettando il completamento dell'I / O. La dimensione della coda di esecuzione e il tempo di attesa I / O sono spesso correlati. Dai un'occhiata anche a sar (dal pacchetto sysstat): che ti dà una visione dettagliata di cosa sta succedendo per un periodo di tempo; le metriche che registra sono molto accurate.