Perché il carico è elevato nonostante il fatto che né la CPU né il disco siano abusati

Sto ottenendo il seguente output da top:

Cpu(s): 43.8%us, 32.5%sy,  4.8%ni,  2.0%id, 15.6%wa,  0.2%hi,  1.2%si,  0.0%st
Mem:  16331504k total, 15759412k used,   572092k free,  4575980k buffers
Swap:  4194296k total,   260644k used,  3933652k free,  1588044k cached

l'output di iostat -xk 6mostra quanto segue:

Device: rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda       0.00   360.20   86.20  153.40  1133.60  2054.40    26.61     1.51    6.27   0.77  18.38
sdb       0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdd      22.60   198.80   17.40   31.60   265.60   921.60    48.46     0.18    3.70   1.67   8.20
sdc      16.80   218.20   22.20   23.40   261.60   966.40    53.86     0.21    4.56   1.49   6.78

Sulla base di quanto sopra sembra che qualcosa debba essere sovraccarico. Ma cosa?

Domande

1. Se non è il disco rigido o la CPU, allora?
2. Sembra che il 15,6% del tempo della CPU sia trascorso in attesa. Cosa potrebbe aspettarsi esattamente?

Come punto di chiarimento, il carico non è direttamente collegato alla CPU. Questa è una delle idee sbagliate più comuni sul carico. Il fatto che tu menzioni il disco sembra riconoscere che ne sei consapevole, ma volevo solo menzionarlo mentre vedo commenti che indicano che alcuni credono diversamente.

Il carico è definito come il numero di processi in attesa di risorse di sistema. In genere si tratta di CPU, disco o rete, ma in realtà può essere qualsiasi hardware.
Neanche un "processo" è necessariamente un processo completo. Un thread viene definito come un "processo leggero" e ogni thread in attesa aumenta il conteggio del carico.

Per capire quali processi sono un problema:

Esegui top -H( -Habilita la visualizzazione dei thread)

Le scorciatoie da tastiera variano in base alla versione.

Con la parte superiore più recente (3.3 e successive):

Premere fper visualizzare le opzioni del campo.
Utilizzare i tasti freccia per andare a S = Process Statuse premere s.
Premere qper tornare alla pagina principale.
Premere Shift+ Rper invertire l'ordinamento.

Con la parte superiore più vecchia (prima della 3.3):

Premi Shift+ oper visualizzare le opzioni di ordinamento.
Quindi wper ordinare in base allo stato del processo.
Quindi Enterper tornare alla pagina principale.
Quindi Shift+ Rper invertire l'ordinamento.

Quindi nella Scolonna, cerca i processi che hanno Do R(dovrebbero essere ora in alto). Questi saranno processi che contribuiranno al caricamento del sistema.

Se il processo mostra a D, significa "sonno ininterrotto". Di solito ciò si verifica quando il processo è in attesa su I / O (disco, rete, ecc.).
Se il processo mostra a R, significa che sta facendo un normale calcolo.

Per saperne di più su cosa stanno facendo questi processi:

Con la parte superiore più recente (3.3 e successive):

Premere fper visualizzare le opzioni del campo.
Utilizzare i tasti freccia per andare a WCHAN = Sleeping in Functione premere dper abilitarlo.
Quindi qper tornare alla pagina principale.

Con la parte superiore più vecchia (prima della 3.3):

Premere fquindi yper abilitare il WCHANcampo.

Se il tuo sistema ha le opzioni del kernel necessarie e il file wchan è presente sul tuo sistema (ho dimenticato dove si trova e come si chiama) , il WCHANcampo dovrebbe mostrarti quale funzione del kernel è attualmente in esecuzione (se il campo mostra solo un -o ?su tutto, non hai supporto).
Un po 'di Google qui e dovresti essere sulla buona strada.

Se non hai il supporto per wchan, puoi sempre provare stracei processi per scoprire cosa stanno facendo, ma questo è il modo difficile.

Processi di breve durata come la compilazione di lavori o processi falliti in un ciclo spesso non sono visibili negli strumenti di monitoraggio come topo iostat e così via.

In tali casi, Linux Audit Framework aiuterà

Il colpevole, ad esempio un ciclo di fallimento

while :; do gcc /dev/zero ; done >/dev/null 2>&1

Per utilizzare auditd / auditctl:

apt-get install auditd
auditctl -a task,always
ausearch -i -sc execve

rubato dal registro tutti i lanci di processo

Ho avuto una situazione in cui i montaggi NFS erano disconnessi e sfortunatamente ho fatto un errore e non ho usato l'opzione soft mount, quindi molti processi stalati sul mio server Linux, incluso il monitoraggio, lsof e persino sessioni bash ...

Dopo aver smontato i supporti rotti, il sistema sembrava sovraccarico:

top - 00:03:48 up 15 days, 14:56,  3 users,  load average: 29, 21, 20

Sembrava terribile, ma l'utilizzo della CPU era inferiore al 15% e non c'erano I / O su disco. Ho ricevuto alcuni consigli per passare a ps, ma questo non ha aiutato dato che sembrava che i processi stessero dormendo.

Poi man psho salvato la mia notte per dormire e, dopo un'indagine, ho trovato delle bandiere STATUS molto importanti da guardare, poiché in seguito hanno identificato che erano processi bloccati .

Eseguire:

ps -e v

e cerca i processi che hanno Do SLnella colonna STAT. Questi erano come processi di zombi ma non identificati come Z-zombi.

D - significa principalmente attività su disco (I / O), ma anche se si esegue ps -e vpoche volte e anche se iostat 3non si vede alcuna attività, ciò indica che questo è bloccato .

SL - questo significa che ci sono pagine bloccate in memoria di quel processo, quindi se puoi identificare che questo processo non dovrebbe comportarsi in questo modo, è il prossimo candidato possibile se rimane per un periodo più lungo senza cambiamenti.

Dopo le indagini, ho quindi ucciso uno per uno e il mio carico medio del sistema è diventato normale.