Site-ul încarcă serverul: cauzele frecvente și cum reduceți consumul

Tipărire
  • 0

Pe scurt: un site „încarcă serverul” atunci când scripturile lui folosesc mai mult timp de procesor, memorie, interogări în baza de date sau procese simultane decât permite pachetul de găzduire. Site-ul devine lent sau afișează erori, iar în cazurile grave scriptul poate fi oprit ori contul suspendat. Cauza se află aproape mereu în site: lipsa cache-ului de pagini, un plugin greu sau vechi, roboți agresivi, o sarcină programată prost ori o bază de date umflată. Mai jos vedeți cum aflați care este cauza și ce schimbați.

Cum se manifestă consumul excesiv

  • Site-ul se mișcă greu, mai ales în orele aglomerate: vedeți site lent: ce optimizați întâi.
  • Vizitatorii primesc pagina „Resource Limit Is Reached” (eroarea 508): vedeți Resource Limit Is Reached.
  • Primiți de la suportul TopHost un mesaj despre consumul ridicat al contului. În el indicăm scripturile sau procesele implicate, deci începeți cu acestea.
  • În situațiile cele mai grave contul este suspendat: vedeți găzduirea a fost suspendată.

De ce spunem că problema este în site

Când un site merge greu, ne uităm întâi la server în ansamblu. Dacă încărcarea generală este normală, iar celelalte site-uri de pe același server răspund repede, problema stă în scripturile acelui site. CloudLinux îi dă fiecărui cont partea lui de procesor, memorie și procese, așa că un site nu își poate încetini vecinii, dar ajunge la propriul plafon. Ce înseamnă fiecare limită aflați din limitele din Resource Usage.

Pasul 1. Vedeți când și cum sunt atinse limitele

  1. În cPanel deschideți Metrics, apoi Resource Usage. Observați ce limită a fost atinsă (CPU, memorie, procese de intrare, IO) și la ce ore.
  2. Comparați acele ore cu jurnalul de acces (Metrics, apoi Raw Access) sau cu Awstats. Multe cereri într-un timp scurt de la aceleași adrese arată spre roboți; încărcarea mare noaptea arată spre sarcinile programate.
  3. Verificați Errors din Metrics sau fișierul error_log din dosarul site-ului. Erorile PHP repetate vin adesea de la un singur plugin; vedeți cum găsiți în error_log pluginul vinovat.
  4. Gândiți-vă ce s-a schimbat recent: un plugin nou, o actualizare, un import de produse, o campanie publicitară, un buletin informativ cu link spre site.

Pasul 2. Eliminați cauzele cele mai frecvente

Lipsa cache-ului de pagini

Fără cache, la fiecare vizită rulează din nou PHP și zeci de interogări în baza de date. Pe WordPress Hosting și Business Hosting activați LiteSpeed Cache: configurarea LiteSpeed Cache. Pe Web Hosting SSD folosiți cache-ul inclus în CMS sau un plugin de cache. În Joomla cache-ul paginilor se setează în System, Global Configuration, fila System.

Extensii vechi sau grele

Versiunile vechi ale CMS-ului și ale pluginurilor sunt mai lente și mai des exploatate. Actualizați-le, pentru WordPress în primul rând din cPanel cu WP Toolkit. Apoi căutați-le pe cele grele: pluginuri de statistici și de „articole similare” care interoghează baza de date la fiecare pagină, constructori de pagini cu multe module, pluginuri de securitate cu scanări complete dese, pluginuri de backup care lucrează direct pe site-ul activ. Dezactivați-le pe rând și urmăriți Resource Usage.

Roboți și crawlere

Crawlerele SEO și roboții care nu respectă regulile pot deschide mii de pagini pe oră, mai ales combinațiile fără sfârșit de filtre și rezultate de căutare din magazinele online. Cum îi recunoașteți și îi limitați: prea mulți roboți pe site. Și încercările de ghicire a parolei pe wp-login.php și xmlrpc.php creează încărcare; protecția este descrisă în securitatea WordPress.

Sarcinile programate

  • În cPanel deschideți Advanced, apoi Cron Jobs. Ștergeți sarcinile duplicate și pe cele care rulează în fiecare minut fără să fie nevoie.
  • WordPress are propriul planificator (WP-Cron), care pornește la vizite. Pe un site cu mult trafic dezactivați-l adăugând define( 'DISABLE_WP_CRON', true ); în wp-config.php și creați în schimb o sarcină cron la fiecare 15 minute, de exemplu: curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1 (puneți domeniul dvs. în locul example.com).

Baza de date

Tabelele care cresc fără limită (revizii, jurnale ținute de pluginuri, date temporare expirate, sesiuni vechi) încetinesc fiecare interogare. Curățați-le cu instrumentele CMS-ului sau cu un plugin dedicat, după ce ați făcut o copie a bazei de date. În phpMyAdmin puteți selecta tabelele și alege Optimize table din lista „With selected”; dacă un tabel apare ca deteriorat, folosiți Repair table. Tabelele mari fără indexuri sunt o sarcină pentru dezvoltator.

Versiune veche de PHP

Versiunile noi de PHP rulează același cod vizibil mai repede. Dacă CMS-ul și pluginurile o suportă, alegeți o versiune recentă: selectarea versiunii PHP.

Scripturi infectate

O încărcare apărută brusc, fără nicio schimbare din partea dvs., poate veni de la cod malițios care trimite spam sau atacă alte site-uri. Verificați contul după pașii din cod malițios pe site: cum îl găsiți.

Dacă ați primit de la noi o notificare despre încărcare

  1. Citiți lista de scripturi și procese din mesaj și începeți cu ele.
  2. Aplicați remedierea potrivită de la Pasul 2 sau transmiteți mesajul dezvoltatorului site-ului.
  3. Răspundeți în același tichet cu ce ați schimbat, ca să putem verifica din nou încărcarea.

Conform Termenilor și condițiilor TopHost, când un cont folosește resurse semnificative, îl contactăm pe client. Dacă utilizarea este excesivă (memorie, procesor, interogări SQL) și poate destabiliza serverul, contul poate fi suspendat sau scriptul dezactivat fără notificare prealabilă, pentru ca serverul să funcționeze pentru toți. O reacție rapidă la mesajul nostru evită acest lucru.

Întrebări frecvente

Site-ul a mers ani la rând fără schimbări. De ce încarcă serverul acum?

Poate că site-ul nu s-a schimbat, dar s-a schimbat totul în jurul lui: mai mult conținut în baza de date, mai mulți vizitatori, roboți noi, pluginuri rămase fără actualizări. O bază de date care a crescut ani de zile este o cauză frecventă.

E momentul pentru un pachet mai mare?

Dacă site-ul este optimizat (cache activ, extensii actualizate, roboți ținuți sub control) și Resource Usage arată în continuare limite atinse la trafic obișnuit, atunci da. Solicitarea unui pachet cu resurse mai mari revine clientului: schimbarea pachetului. Pentru proiectele care au depășit găzduirea comună, vedeți când aveți nevoie de un VPS.

Îmi puteți spune ce script este problema?

Da. Deschideți un tichet de suport cu adresa site-ului și ora la care a apărut problema, iar noi ne uităm la procesele înregistrate pentru contul dvs.

Articole utile

Răspunsul a fost util?