Load average w Linux – interpretacja, progi i diagnoza przeciążenia

Przez /

Load average jest często pierwszą liczbą, którą administrator sprawdza po zgłoszeniu „serwer działa wolno”. Sama liczba nie oznacza procentu zajętości procesora. W Linux uwzględnia zadania gotowe do pracy na CPU oraz zadania w nieprzerywalnym oczekiwaniu, zwykle na I/O. Dlatego load 8 może oznaczać zarówno osiem pracujących wątków, jak i procesy stojące na dysku.

1. Jak odczytać trzy wartości i co oznacza ich kierunek

uptime
cat /proc/loadavg
nproc
lscpu | grep -E '^CPU\(s\)|^On-line CPU|^Thread|^Core'

Przykład: load average: 2.50, 1.80, 0.90 to wykładniczo wygładzone wartości dla około 1, 5 i 15 minut, a nie trzy niezależne liczniki operacji. Jeśli 1-minutowy load jest większy od 5- i 15-minutowego, presja narasta. Odwrotna relacja zwykle oznacza wygaszanie obciążenia. Nie używaj tych średnich do wykrywania pojedynczych, kilkusekundowych skoków.

2. Load podzielony przez logiczne CPU – przykłady

Jako pierwszy punkt odniesienia oblicz load / liczbę logicznych CPU dostępnych dla danej pracy. To wskaźnik orientacyjny, nie procent użycia CPU ani automatyczny alarm. Przykłady: load 0.5 na jednym CPU to niewielka średnia liczba zadań; load 2.5 na czterech CPU to około 0.625 zadania na CPU; ale load 2.5 na dwóch CPU to już około 1.25, czyli przy obciążeniu czysto obliczeniowym może powstawać kolejka. Load 16 na 16 CPU nie dowodzi awarii – może oznaczać pełne użycie zasobów.

Przybliżona interpretacja dla obciążenia CPU-bound: wynik normalizowany trwale poniżej 0.7 często oznacza pewien zapas; pasmo 0.7–1.0 wymaga kontroli opóźnień i pory dnia; ponad 1.0 przez kilka minut sugeruje kolejkę zadań. To wyłącznie heurystyki operacyjne, nie twarde normy. Aplikacja wrażliwa na opóźnienia może mieć problem wcześniej, a wsadowe obliczenia mogą poprawnie pracować powyżej 1.0.

3. Gdzie normalizowanie bywa błędne

W maszynie wirtualnej może występować steal (hipernadzorca nie przydziela czasu). W kontenerze nproc i liczba widocznych CPU mogą nie odzwierciedlać limitu CPU cgroup; zobacz cpu.max oraz cpuset.cpus.effective. Przykładowo quota 200000 100000 odpowiada dwóm CPU czasu wykonania, mimo że host ma ich 32. W cgroup v1 sprawdzaj odpowiednie limity starszego interfejsu.

cat /sys/fs/cgroup/cpu.max 2>/dev/null
cat /sys/fs/cgroup/cpuset.cpus.effective 2>/dev/null
cat /proc/pressure/cpu 2>/dev/null

4. Load wysoki, CPU bezczynny – rozpoznaj typ D

Gdy load jest wysoki, a CPU jest w większości idle, sprawdź procesy w stanie D, dysk i sieciowe systemy plików. Zadanie w D nie musi zużywać CPU; może czekać na dysk, NFS, sterownik lub inny zasób. Zabicie procesu w takim stanie niekoniecznie zadziała, dopóki nie ustanie oczekiwanie w jądrze.

ps -eo pid,ppid,stat,wchan:32,comm --sort=stat
vmstat 1 10
iostat -xz 1 10
cat /proc/pressure/io 2>/dev/null

W vmstat istotne są r (gotowe do CPU) i b (zablokowane, zwykle I/O). Jeśli r stale przekracza dostępną liczbę CPU, a wa jest małe, podejrzewaj CPU. Jeżeli rośnie b, opóźnienia await i presja io, badaj storage. wa nie jest prostym procentem wykorzystania dysku i samodzielnie nie przesądza o awarii.

5. Przykład diagnostyczny – 4 vCPU, load 8.0

Sytuacja A: vmstat r=9, b=0, us+sy=95%, wa=0%, opóźnienia aplikacji rosną. Wniosek: silny kandydat na niedobór CPU, sprawdź najbardziej aktywne procesy i throttling cgroup. Sytuacja B: r=1, b=7, id=70%, wa=25%, iostat await rośnie z 2 do 45 ms. Wniosek: load napędza raczej I/O niż obliczenia. Sytuacja C: CPU i storage bez presji, usługa działa poprawnie – chwilowe load 8 po zadaniu cron może nie wymagać interwencji.

6. Kiedy rzeczywiście alarmować

  • Ustaw osobne progi dla typowych godzin, rodzaju usługi i liczby CPU; porównaj z historyczną bazą.
  • Łącz wysoki load z rosnącym P95/P99 latency, kolejką żądań, błędami lub PSI – sam load nie jest wskaźnikiem jakości usługi.
  • Wykresuj load 1/5/15 min i CPU/PSI; pojedynczy pik traktuj inaczej niż 15 minut utrzymującej się presji.
  • Dla kontenerów obserwuj również cpu.stat (m.in. nr_throttled i throttled_usec).

Źródła i dalsza diagnostyka

Podstawa definicji: proc_loadavg(5); uzupełnienie: Linux PSI. Artykuł nadrzędny: Diagnostyka wydajności Linux – CPU, RAM i I/O.

Przewijanie do góry