Monitorizarea resurselor serverului în cPanel

Monitorizarea resurselor serverului în cPanel este singurul mod de a afla de ce un site pe găzduire partajată devine lent sau afișează eroarea 508 la ore de vârf. Contul are limite de procesor, memorie, procese și acces la disc, iar când una dintre ele este atinsă, serverul pune cererile în așteptare sau le refuză. cPanel arată exact care limită și când.

Articolul explică uneltele din panou, semnificația fiecărei valori, cauzele pe care le găsim cel mai des la clienți și măsurile care reduc consumul fără să schimbați planul de găzduire.

Monitorizarea resurselor serverului în cPanel

Pe majoritatea găzduirilor partajate din România, serverul rulează CloudLinux, care izolează fiecare cont într-un mediu cu limite proprii (LVE). cPanel expune aceste limite prin unealta Resource Usage, din secțiunea Metrics. Pe serverele fără CloudLinux, unealta se numește CPU and Concurrent Connection Usage și arată mai puține detalii, dar principiul este același.

Unde găsiți datele

• Bara laterală Statistics: spațiul pe disc, traficul lunar, numărul de conturi de e-mail, baze de date și domenii față de limitele planului. Este prima privire, fără clic.
• Metrics, Resource Usage: pagina principală, cu mesajul „Your site has been limited within the past 24 hours” dacă a existat o depășire, graficele pe zi sau pe lună și instantaneele.
• Metrics, Disk Usage: ce dosare ocupă spațiul, util când limita de disc e cea atinsă.
• Metrics, Bandwidth: traficul pe zile, separat pe web, e-mail și FTP.

Ce înseamnă fiecare limită

1. CPU: procentul din procesor alocat contului; 100% înseamnă un nucleu întreg. Când e atins, cererile nu sunt refuzate, ci încetinite.
2. Physical Memory (PMEM): memoria reală folosită de toate procesele contului, PHP în primul rând. La depășire, procesele sunt oprite și apar erori 500 sau 503.
3. Entry Processes (EP): numărul de cereri PHP tratate simultan. Este limita atinsă cel mai des, de obicei 20 sau 30. La depășire apare eroarea 508 Resource Limit Is Reached.
4. Number of Processes (NPROC): totalul proceselor, inclusiv cron și SSH.
5. I/O și IOPS: viteza de citire și scriere pe disc și numărul de operații pe secundă. Le ating site-urile cu baze de date mari sau cu copii de siguranță rulate în orele de vârf.
6. Inodes: numărul de fișiere și dosare. Se atinge din cache-uri necurățate și din e-mailuri nefiltrate; contul nu mai poate crea niciun fișier nou.

Fiecare limită are un grafic cu utilizarea medie, vârful și numărul de erori (faults). Un vârf ocazional nu e o problemă; erorile repetate în același interval al zilei sunt.

Instantaneele: cine a consumat

Butonul Snapshots deschide o listă cu momentele în care contul a atins o limită. Fiecare instantaneu arată procesele care rulau, cu adresa cerută, timpul de procesor și memoria consumată, plus interogările din baza de date aflate în execuție. Aici se vede diferența dintre un site vizitat de oameni și unul cerut de roboți: în al doilea caz, aceleași adrese de filtrare sau de căutare apar de zeci de ori, de la aceleași adrese IP.

Pentru corelare, deschideți în paralel jurnalele de acces și de erori la ora instantaneului. Metoda completă de diagnosticare, de la simptom la cauză, este descrisă în ghidul despre diagnosticarea problemelor de găzduire cu Metrics.

Cauzele pe care le găsim cel mai des

• Roboți care parcurg pagini de filtrare: un magazin cu 200 de produse și 15 filtre are sute de mii de adrese posibile, iar roboții le cer pe toate. Blocarea din IP Deny Manager sau reguli în robots.txt și .htaccess reduc consumul imediat.
• Lipsa cache-ului: fiecare vizită rulează PHP și baza de date de la zero. Un modul de cache pentru pagini și un cache de obiecte cu Redis, unde e disponibil, scad EP și CPU de câteva ori.
• wp-cron sau sarcini programate care rulează la fiecare vizită: se dezactivează în aplicație și se mută în cronurile din cPanel, o dată la 15 minute.
• Versiune PHP veche: PHP 7.4 consumă mai mult decât 8.3 pentru aceeași pagină. Schimbarea se face din MultiPHP Manager.
• Baze de date neoptimizate: tabele cu milioane de rânduri de jurnal sau de sesiuni. Curățarea și indexarea, descrise în articolul despre optimizarea bazelor de date din cPanel, reduc I/O.
• Module sau teme cu erori: un modul care scrie zeci de avertismente PHP la fiecare cerere consumă disc și procesor pentru nimic.
• Copii de siguranță în orele de vârf: arhivarea unui site de 5 GB la ora 10 dimineața atinge I/O-ul pentru toată lumea. Programați-le noaptea.
• Cod compromis: un script de spam sau un miner de criptomonede rulează continuu. Instantaneele arată fișiere PHP cu nume necunoscute; pașii de curățare sunt în ghidul despre securitatea contului de găzduire.

Cum citiți situația într-un exemplu

Un site de rezervări avea erori 508 în fiecare zi între 9 și 11. Resource Usage arăta EP la limita de 20 în acel interval, CPU la 60%, memorie la 40%. Instantaneele conțineau 18 procese PHP pentru aceeași adresă, calendarul de disponibilitate, cerute de un serviciu de monitorizare configurat la 5 secunde. După rărirea verificărilor la 5 minute și activarea cache-ului pe pagina calendarului, EP a scăzut la 3 în vârf. Planul de găzduire a rămas același.

Într-un alt caz, un blog cu 300 de vizite pe zi atingea limita de inodes. Disk Usage arăta 400.000 de fișiere în dosarul de cache al unui modul de imagini, care păstra fiecare variantă generată. Curățarea și limitarea variantelor au coborât numărul la 40.000.

Din terminal, când interfața nu ajunge

Dacă găzduirea permite accesul la terminalul din cPanel, câteva comenzi arată în timp real ce se întâmplă în cont:

top -u $USER                       # procesele contului, ordonate după CPU
ps aux --sort=-%mem | head -10      # cele mai mari consumatoare de memorie
du -sh ~/public_html/* | sort -rh | head   # ce ocupă spațiul
find ~ -type f | wc -l              # numărul de fișiere (inodes)

Pe un server propriu, aceleași întrebări au răspuns în htop și atop, care păstrează și istoricul consumului pe ore.

Avertismentele pe e-mail și ce faceți cu ele

Multe găzduiri trimit automat un e-mail când contul atinge o limită, cu textul „Resource limit reached” sau „Your account has been limited”. Mesajul conține limita atinsă și intervalul. Nu îl ignorați și nu răspundeți prin trecerea imediată la un plan superior: deschideți Resource Usage, comparați ora din e-mail cu instantaneele și căutați cauza în lista de mai sus. În aproximativ două treimi din cazurile pe care le-am văzut, cauza a fost un robot sau lipsa cache-ului, iar planul a rămas același.

Al doilea tip de avertisment privește spațiul pe disc sau inodes, la 80% și la 95% din cotă. La 100% contul nu mai poate scrie nimic: e-mailurile noi sunt respinse, sesiunile de autentificare eșuează, copiile de siguranță ale furnizorului sar peste cont. Curățarea începe cu Disk Usage și, aproape întotdeauna, cu dosarele de cache, cu e-mailurile vechi din dosarele spam și trash și cu arhivele de copii de siguranță uitate în public_html.

Întrebări frecvente

1. Limitele se aplică pe cont sau pe site? Pe cont. Trei site-uri pe același cont împart aceeași limită de procesor și de procese; unul lent le încetinește pe toate.
2. Traficul de la Google consumă resurse? Da, ca orice vizită. Un site cu mii de pagini indexate primește zilnic sute de accesări de la Googlebot; cache-ul le face ieftine.
3. De ce apare 508 când site-ul nu are vizitatori? Din cauza roboților, a sarcinilor programate sau a unui script compromis. Instantaneele arată care.
4. Graficul arată consum și noaptea. E normal? Dacă rulează copii de siguranță, cronuri sau reindexări, da. Dacă nu ați programat nimic, verificați jurnalele de acces pentru ora respectivă.
5. Pot cere furnizorului să ridice o singură limită? Unii furnizori oferă suplimente de EP sau memorie fără schimbarea planului. Merită întrebat, cu datele din Resource Usage la îndemână.

Când chiar aveți nevoie de un plan mai mare

Dacă, după cache, blocarea roboților și actualizarea PHP, consumul mediu rămâne peste 70% din limită în orele obișnuite, iar traficul crește, planul este subdimensionat. Semnele: CPU la limită cu instantanee în care apar doar pagini normale, de la vizitatori diferiți; memoria atinsă de procese PHP cu consum firesc, sub 64 MB fiecare; I/O atins de interogări simple. În acest punct, un plan cu limite mai mari sau un server virtual costă mai puțin decât orele de optimizare rămase.

Înainte de mutare, faceți o copie de siguranță completă și verificați că noul plan raportează aceleași valori în Resource Usage, ca să comparați corect. Pentru orientare generală în panou, ghidul pentru începători în cPanel descrie fiecare secțiune amintită aici.

Surse

• Documentația cPanel, Metrics: uneltele Resource Usage, Bandwidth, Disk Usage și CPU and Concurrent Connection Usage.
• Documentația cPanel: descrierea interfeței și a secțiunilor panoului.