Uneori aplicatia pare lenta fara ca problema sa fie neaparat in frontend, webserver sau baza de date. Serverul raspunde greu, paginile se incarca lent, apar timeout-uri, iar primul impuls este sa cauti problema in requesturile utilizatorilor.
Dar destul de des merita sa te uiti si in spate.
Poate fi un worker, o sincronizare, o indexare, o generare de rapoarte, un rebuild de cache, o procesare de fisiere sau orice alt job programat. Luat separat, fiecare pare normal. Problema apare cand aceste procese ruleaza in paralel, fara limite clare, pe acelasi server pe care ruleaza si aplicatia principala.
Pe o masina cu 8 vCPU, de exemplu, nu inseamna ca poti consuma linistit 6 vCPU cu joburi de fundal si sa te astepti ca restul aplicatiei sa se comporte la fel. Sistemul mai are nevoie de CPU pentru webserver, runtime-ul aplicatiei, baza de date, procese de sistem, logging, cache, conexiuni active si tot ce mai ruleaza acolo.
Cand procesele de fundal imping sistemul in saturatie, lucrurile nu crapa mereu spectaculos. De multe ori serverul inca raspunde, dar raspunde prost.
CPU-ul ajunge aproape sau chiar la 100%, iar requesturile nu dispar. Se pun la coada. Webserverul asteapta, aplicatia asteapta, utilizatorul asteapta. De aici apar pagini lente, actiuni care par blocate, timeout-uri si senzatia ca “site-ul merge greu”, desi problema reala poate fi in alta parte.
Aici se vede diferenta intre “serverul functioneaza” si “serverul mai are resurse sanatoase pentru workload-ul real”. Nu este suficient ca serviciile sa fie active si porturile sa raspunda. Daca CPU-ul este plin, load-ul creste, iowait-ul urca sau procesele stau la coada dupa timp de executie, aplicatia incepe sa piarda din latenta.
Un thread activ nu este doar un numar intr-o configuratie. Daca face parsare, validari, conversii, query-uri, compresie, apeluri externe sau I/O intens, poate deveni rapid un consumator real de resurse. Iar cand ai mai multe astfel de thread-uri in paralel, ele nu ruleaza intr-un gol. Ruleaza pe aceeasi masina cu restul aplicatiei.
De asta documentatia unei aplicatii trebuie citita cu putina prudenta. De multe ori, documentatia vorbeste despre minimul necesar pentru instalare sau functionare. Nu neaparat despre productie, trafic real, cron-uri, worker-e, procesari grele, indexari, cache rebuild si utilizatori activi in acelasi timp.
Cand apare o situatie de genul asta, nu presupune direct ca problema este in webserver. Verifica intai ce se intampla pe masina.
Comenzi utile:
top sau htop pentru procesele care consuma CPU
uptime pentru load average
mpstat pentru distributia consumului pe CPU-uri
iostat pentru disk I/O si iowait
pidstat pentru consum pe proces sau thread
journalctl pentru mesaje de sistem
logurile aplicatiei pentru joburi pornite, erori, timeout-uri sau procesari lenteDaca vezi ca procesele de fundal consuma constant CPU sau cresc iowait-ul, iar in acelasi timp aplicatia raspunde greu, ai deja o pista buna.
Mitigarea nu inseamna automat server mai mare. Uneori ajuta, dar daca workload-ul ramane fara limite, problema doar se muta mai sus.
Mai sanatos este sa controlezi cum ruleaza aceste joburi: mai putine thread-uri, intervale in afara orelor de varf, queue-uri, limite de resurse, worker-e separate sau chiar separarea completa intre frontend si procesele grele de fundal.
Concluzia practica este simpla: uneori serverul nu este slab. Doar este pus sa faca prea multe lucruri in acelasi timp, fara prioritati clare.