Dlaczego obciążenie jest wysokie, mimo że ani procesor, ani dysk nie są nadmiernie wykorzystane

Otrzymuję następujące dane wyjściowe z 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

dane wyjściowe iostat -xk 6pokazują, co następuje:

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

Na podstawie powyższego wygląda na to, że coś musi zostać przeciążone. Ale co?

pytania

1. Jeśli to nie dysk twardy ani procesor, to co?
2. Wygląda na to, że 15,6% czasu procesora spędza na oczekiwaniu. Na co dokładnie może czekać?

Jako wyjaśnienie, obciążenie nie jest bezpośrednio związane z procesorem. Jest to jedno z najczęstszych nieporozumień dotyczących obciążenia. Fakt, że wspomniałeś o dysku, zdaje się potwierdzać, że jesteś tego świadomy, ale chciałem o tym wspomnieć, ponieważ widzę komentarze, które wskazują, że niektórzy uważają inaczej.

Obciążenie jest definiowane jako liczba procesów oczekujących na zasoby systemowe. Zazwyczaj jest to procesor, dysk lub sieć, ale tak naprawdę może to być dowolny sprzęt.
„Proces” niekoniecznie musi być pełnym procesem. Wątek jest definiowany jako „lekki proces”, a każdy oczekujący wątek zwiększa liczbę obciążeń.

Aby dowiedzieć się, które procesy stanowią problem:

Uruchom top -H( -Humożliwia wyświetlanie wątków)

Skróty klawiaturowe różnią się w zależności od wersji.

Z nowszą górą (3.3 i później):

Naciśnij, faby wyświetlić opcje pola.
Użyj klawiszy strzałek, aby przejść do S = Process Statusi naciśnij s.
Naciśnij, qaby wrócić do strony głównej.
Naciśnij Shift+, Raby odwrócić sortowanie.

Ze starszą górą (przed 3.3):

Naciśnij Shift+, oaby wyświetlić opcje sortowania.
Następnie wposortuj według statusu procesu.
Następnie Enterwróć do strony głównej.
Następnie Shift+, Raby odwrócić sortowanie.

Następnie w Skolumnie poszukaj procesów, które mają Dlub R(powinny być teraz na górze). Będą to procesy przyczyniające się do obciążenia systemu.

Jeśli proces pokazuje a D, oznacza to „nieprzerwany sen”. Zwykle dzieje się tak, gdy proces oczekuje na We / Wy (dysk, sieć itp.).
Jeśli proces pokazuje a R, oznacza to, że wykonuje zwykłe obliczenia.

Aby dowiedzieć się więcej o tym, co robią te procesy:

Z nowszą górą (3.3 i później):

Naciśnij, faby wyświetlić opcje pola.
Użyj klawiszy strzałek, aby przejść do WCHAN = Sleeping in Functioni naciśnij, daby włączyć.
Następnie, qaby wrócić do strony głównej.

Ze starszą górą (przed 3.3):

Naciśnij fnastępnie, yaby włączyć WCHANpole.

Jeśli twój system ma niezbędne opcje jądra, a plik wchan jest obecny w twoim systemie (zapominam, gdzie to jest i jak się nazywa) , WCHANpole powinno pokazywać, jaką funkcję jądra aktualnie działa proces (jeśli pole pokazuje tylko -lub ?na wszystko, nie masz wsparcia).
Trochę google tutaj i powinieneś być w drodze.

Jeśli nie masz wsparcia, zawsze możesz wypróbować straceprocesy, aby dowiedzieć się, co robią, ale to trudny sposób.

Procesy o krótkim czasie życia, takie jak kompilowanie zadań lub procesy zakończone niepowodzeniem, często nie są widoczne w narzędziach do monitorowania, takich jak topiostat i tak dalej.

W takich przypadkach pomoże Linux Audit Framework

Sprawca, na przykład pętla awarii

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

Aby użyć auditd / auditctl:

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

skradzione z dziennika uruchamianie wszystkich procesów

Miałem sytuację, gdy podłączenia NFS zostały rozłączone i niestety popełniłem błąd i nie użyłem opcji miękkiego montażu, dlatego wiele procesów zostało wstrzymanych na moim serwerze Linux, w tym sesje monitorowania, lsof, a nawet bash ...

Po odmontowaniu zepsutych mocowań system wyglądał na przeciążony:

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

Wyglądało to okropnie, ale użycie procesora poniżej 15% i nie ma dyskowych operacji we / wy. Dostałem kilka rad, aby przejść przez ps, ale to nie pomogło, ponieważ wyglądało na to, że procesy w większości śpią.

Potem man psuratowałem swoją noc na sen, a po dochodzeniu znalazłem bardzo ważne flagi STATUS, na które należy spojrzeć, ponieważ później zidentyfikowałem, że były to zablokowane procesy.

Wykonać:

ps -e v

i poszukaj procesów, które mają Dlub SLw kolumnie STAT. Były jak procesy zombie, ale nie zostały zidentyfikowane jako Z-zombie.

D - oznacza głównie aktywność dysku (I / O), ale także jeśli uruchomisz ps -e vkilka razy, a także iostat 3nie zobaczysz żadnej aktywności, oznacza to, że zablokował się we / wy .

SL - oznacza to, że w pamięci tego procesu są zablokowane strony, więc jeśli możesz stwierdzić, że ten proces nie powinien zachowywać się w ten sposób, następnym możliwym kandydatem będzie pozostanie przez dłuższy czas bez zmian.

Po zakończeniu dochodzenia zabijałem jeden po drugim, a średnie obciążenie mojego systemu stało się normalne.