`Ghid de Depanare a Incidentelor în Producție: Analiza CPU Spike, Memory OOM Killer și Disk I/O Saturation` în Linux / Bash

Procese și monitorizare Standard Producție

Ghid practic de triaj și depanare a serverelor Linux sub criză: metodologia USE în 60 de secunde, investigarea proceselor ucise de OOM Killer și rezolvarea inodurilor epuizate.

Sintaxă comandă

uptime | dmesg -T | grep -i oom | df -i | vmstat 1

Când primești o alertă pe PagerDuty sau Slack că serverul de producție nu mai răspunde la comenzi, panica și rularea la întâmplare a comenzilor nu ajută. Inginerul de performanță Brendan Gregg (Netflix) a dezvoltat Metodologia USE (Utilization, Saturation, Errors): un set de comenzi de triaj care permit identificarea cauzei rădăcină în sub 60 de secunde.

Protocolul de Urgență: Primele 4 comenzi de rulat pe server

# 1. Verificăm Load Average-ul și timpul de funcționare:
uptime
# Dacă Load Average depășește numărul total de nuclee CPU (verificabil cu nproc), sistemul este suprasaturat!

# 2. Verificăm memoria RAM liberă și swap-ul:
free -m
# Urmăriți coloana 'available' (memoria reală disponibilă pentru aplicații noi).

# 3. Verificăm spațiul pe discuri:
df -h
df -i # CRITIC: Verifică procentul de INODURI consumate!

# 4. Verificăm activitatea pe procese și I/O în timp real:
vmstat 1 5
# Coloana 'r' = procese care așteaptă CPU.
# Coloana 'b' = procese blocate în așteptare de I/O pe disc!

Misterul Linux OOM Killer (Out-of-Memory Killer)

Scenariu clasic: un serviciu critic (de exemplu baza de date MySQL sau un worker Node.js) dispare brusc fără nicio eroare în propriul fișier de log. Cauza este de regulă OOM Killer — mecanismul extrem al kernel-ului Linux care, atunci când memoria RAM și swap-ul s-au epuizat complet, sacrifică procesul cu cel mai mare scor de consum de memorie pentru a preveni prăbușirea întregului sistem de operare:

Detectarea victimelor OOM Killer în jurnalele de kernel

# Verificăm ultimele mesaje de kernel timestamp-ate uman:
sudo dmesg -T | grep -i -E 'killed process|out of memory'

# Output revelator:
# [Thu Oct 24 18:25:10 2026] Out of memory: Killed process 14820 (mysqld) total-vm:8450120kB, anon-rss:6201400kB
# -> Kernel-ul a ucis procesul MySQL pentru că nu mai exista memorie fizică liberă!

# Soluție pe termen scurt: Adăugați un fișier de swap de siguranță sau reduceți buffer pool-ul din MySQL.

Problema Inodurilor Epuizate (100% Inodes)

Dacă o comandă returnează No space left on device, dar comanda df -h arată zeci de gigaocteți liberi, cauza este epuizarea inodurilor. Fiecare fișier creat pe un sistem de fișiere ext4 consumă exact un inod. Dacă o aplicație a creat 5 milioane de fișiere mici de sesiune sau imagini temporare, inodurile se termină înainte de a umple spațiul fizic:

Identificarea folderului care conține milioane de fișiere mici

# Verificăm consumul de inoduri:
df -i
# Dacă /dev/sda1 arată 'IUse% = 100%', inodurile sunt epuizate!

# Script rapid pentru a găsi directorul vinovat:
sudo find /var/ -maxdepth 3 -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 -type f | wc -l' \; | sort -k2 -nr | head -n 5