Scripturile PHP se încarcă brusc foarte lent pe Apache

Testez de ce uneori scripturile mele PHP durează mult să se încarce prin rețea (>30sec) pe serverul meu Ubuntu Apache 2.4 cu PHP-FPM 7.4 folosind mpm_event. Serverul a funcționat normal în ultimele luni, asta a început să se întâmple acum câteva zile și nu am schimbat nimic. Am facut un reboot, nu a ajutat.

Am făcut un simplu test.php. Uneori se încarcă normal (<100 ms), dar uneori durează 1 minut să se încarce:

<?php echo "test\n"; ?>

• CPU, RAM și IO ale serverului sunt toate normale (verificate cu htop).
• Fișierele HTML statice sunt încărcate fără întârzieri.
• Rularea scriptului local prin consola SSH este foarte rapidă.
• Jurnalele de erori Apache nu arată nimic neobișnuit.
• Am verificat dacă există vreun atac DDOS verificând numărul de IP-uri conectate de la aceeași subrețea /16 și nu am găsit nimic ciudat (de exemplu, > 100 de conexiuni).

Cum pot depana mai departe acest lucru pentru a vedea de ce se întâmplă acest lucru?

Câteva rezultate de depanare care pot ajuta:

starea serviciului sudo php7.4-fpm

Pot exista mai multe motive pentru acest comportament:

1. Dacă acest server web procesează solicitări din rețeaua externă, atunci odată cu creșterea volumului de trafic, încărcarea ar putea crește, ceea ce a dus la creșterea timpului de răspuns al serverului.
2. Dacă scripturile dumneavoastră folosesc apeluri către resurse externe, atunci în acest caz timpul de răspuns al serverului dumneavoastră poate crește din cauza vitezei scăzute de răspuns a resursei externe.

Jurnal mesaj:

[30-Sep-2021 03:36:46] AVERTISMENT: serverul [pool www] a ajuns la setarea pm.max_children (5), luați în considerare creșterea acestuia

este doar o dovadă a sarcinii crescute.

În ambele cazuri, ar trebui să determinați motivele încărcării analizând numărul de solicitări către scripturi, iar dacă există apeluri către resurse externe, asigurați-vă că acestea funcționează corect.

După cum puteți vedea în starea dvs. de ieșire aveți o sarcină care așteaptă să fie începută (5 active, 0 inactiv, 6 sarcini). Așa cum ați postat în propriul răspuns (și mă bucur că a funcționat), creșterea numărului de copii permisi poate fi o soluție bună - dar există multe lucruri care merg în optimizarea php-fpm și, cu siguranță, ar trebui să se acorde mai multă atenție întregul sistem înainte de a face aceste modificări de configurare.

Un ghid solid este Aici.

Dar indiferent de ceea ce ar trebui să știți când utilizați valori statice:
if (utilizarea memoriei de proces * max_children > RAM)
{ [crash apache] }

if (cerințe de procesare * start_servers > CPU)
{ [crash apache] }

Și întotdeauna cunoaște-ți hardware-ul înainte de a modifica aceste setări, mai ales în dinamică/la cerere (de exemplu, mai ușor de făcut greșeli).

Dacă faceți acest lucru pentru orice tip de server web de afaceri esențial, aș încerca să rotunjesc, apoi să dublez toate estimările. adică cel mai mare proces care poate fi numit folosește 178 MB, deci 200 MB, iar VM-ul dvs. actual pe [inserați furnizorul de găzduire/self] are doar 1 GB RAM - aș seta max_children la 2 -- atunci când upgradezi VM-ul tău (ce faci cu 1 GB în 2021?) și ai 8 GB RAM pe server, poți folosi max_children = 18 Observați că în ambele exemple rotunjirea este în favoarea resurselor suplimentare și, după dublarea pentru scopul fpm, lasă în urmă o bucată de memorie pentru sistemul de operare și alte procese de fundal de utilizat.

Modificarea acestor setări poate fi extrem de utilă, iar oricine folosește apache ar trebui să știe cum - doar asigurați-vă că hardware-ul dvs. poate gestiona configurația software pe care ați configurat-o.

Am avut aproape aceeași problemă anul trecut.

Creșterea numărului maxim de copii va compensa problema doar la o dată ulterioară.

Sa dovedit a fi o bază de date MySQL lentă găzduită pe un server dedicat din rețeaua noastră pentru un blog.

PHP-ul nostru a fost configurat să încerce să se conecteze timp de 30 de secunde și ori de câte ori această bază de date a decis să acționeze, atunci ar fi folosit 100 de copii PHP.

Am coborât-o la 1 secundă și problema a dispărut. Nu-mi amintesc dacă problema bazei de date era legată de rețea sau dacă a trebuit să optimizăm baza de date în sine.

Ar trebui să verificați jurnalul de acces Apache pentru intervalul de timp 2:30-3:30 și să vă dați seama dacă sunt pagini care se conectează la o bază de date. Verificați jurnalul pentru 500 de erori care au dus la colapsul serverului.