Versiunea neredactată a articolului a fost publicată inițial pe și este publicată aici cu permisiunea ei .
Voi descrie pe scurt cum să configurați cel mai bine PHP-FPM pentru a crește capacitatea de procesare, a reduce latența și a utiliza mai stabil resursele CPU și RAM. Implicit, linia PM (manager de procese) în PHP-FPM are valoarea dynamic, iar dacă vă lipsește memorie, este mai bine să setați ondemand. Să comparăm cele 2 opțiuni de gestionare bazate pe documentația php.net și să vedem în ce constă preferința mea static pm pentru un volum mare de trafic:
pm = dynamic — numărul de procese fiice este configurat dinamic pe baza următoarelor directive: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — procesele sunt create la cerere (spre deosebire de crearea dinamică, când pm.start_servers sunt pornite la începutul serviciului).
pm = static — numărul de procese fiice este fixat și este specificat prin parameterul pm.max_children.
Detalii pot fi găsite în .
Similaritățile managerului de procese PHP-FPM cu regulatorul de frecvență a procesorului
Acest lucru poate părea off-topic, dar intenționez să conectez asta cu tema configurării PHP-FPM. Cine nu a experimentat o încetinire a procesorului — pe laptop, mașină virtuală sau server dedicat. Îți amintești de scalarea frecvenței procesorului? Aceste setări, disponibile pentru nix și Windows, pot îmbunătăți performanța și viteza de răspuns a sistemului, dacă modifici setarea regulatorului procesorului de la ondemand pe performance*. De data aceasta, să comparăm descrierile și să vedem asemănările:
Governor = ondemand — scalare dinamică a frecvenței procesorului în funcție de sarcina curentă. Trecere rapidă la frecvența maximă, apoi reducerea acesteia atunci când apar perioade de inactivitate.
Governor = conservative = scalație dinamică a frecvenței în funcție de sarcina curentă. Crește și reduce frecvența mai gradual decât ondemand.
Governor = performance — frecvența este întotdeauna maximă.
Detalii pot fi găsite în .
Vezi asemănarea? Voiam să arăt această comparație pentru a te convinge că este cel mai bine să folosești pm static pentru PHP-FPM.
Pentru regulatorul de procesor, parametrul performance ajută la creșterea sigură a performanței, deoarece aceasta depinde aproape în totalitate de limita CPU-ului serverului. În plus, există și alți factori, cum ar fi temperatura, încărcarea bateriei (în laptop) și alte efecte secundare ale funcționării continue a procesorului la 100%. Configurarea performanței asigură cea mai rapidă funcționare a procesorului. Citiți, de exemplu, despre , cu care panoul RPi va utiliza regulatorul performance, unde îmbunătățirea performanței va fi mai vizibilă din cauza frecvenței CPU-ului scăzute.
Utilizarea pm static pentru atingerea performanței maxime a serverului
Parametrul PHP-FPM pm static depinde în mare măsură de memoria disponibilă pe server. Dacă memoria este limitată, ar fi mai bine să alegeți ondemand sau dynamic. Pe de altă parte, dacă aveți suficientă memorie, puteți evita costurile suplimentare ale managerului de procese PHP, setând pm static la capacitatea maximă a serverului. Cu alte cuvinte, dacă calculele sunt efectuate corect, trebuie setat pm.static la numărul maxim de procese PHP-FPM care pot fi executate, fără a crea probleme cu insuficiența de memorie sau cache. Dar nu atât de mult încât să suprasolicite procesoarele și să acumuleze multe operațiuni PHP-FPM în așteptare.
În captura de ecran de mai sus, serverul are configurat pm = static și pm.max_children = 100, și aceasta ocupă aproximativ 10 GB din cei 32 disponibili. Observați coloanele evidențiate, aici totul este clar. În această captură de ecran, erau aproximativ 200 de utilizatori activi (timp mai mare de 60 de secunde) în Google Analytics. La acest nivel, aproximativ 70% din procesele copil PHP-FPM sunt încă inactivate. Asta înseamnă că PHP-FPM este întotdeauna setat la maximul resurselor serverului, indiferent de traficul actual. Procesul inactiv așteaptă vârful de trafic și reacționează imediat. Nu trebuie să așteptați ca pm să creeze procese copil, iar apoi să le finalizeze atunci când expiră perioada pm.process_idle_timeout. Am setat o valoare foarte mare pentru pm.max_requests, deoarece acesta este un server de lucru fără scurgeri de memorie în PHP. Puteți seta pm.max_requests = 0 cu static, dacă sunteți complet siguri de scripturile PHP actuale și viitoare. Dar este mai bine să reporniți scripturile din când în când. Setați un număr mare de cereri, deoarece dorim să evităm costurile suplimentare pm. De exemplu, cel puțin pm.max_requests = 1000 — în funcție de numărul pm.max_children și de numărul de cereri pe secundă.
În captura de ecran este afișată comanda , filtrat după u (utilizator) și numele utilizatorului PHP-FPM. Afișează doar primele 50 sau acolo procese (nu am numărat exact), dar, în esență, top arată statistici de vârf care sunt plasate în fereastra terminalului. În acest caz, cu sortarea după %CPU.
top -bn1 | grep php-fpmCând să folosești pm ondemand și dynamic
Dacă folosești pm dynamic, apar erori similare:
AVERTIZARE: [pool xxxx] pare ocupat (s-ar putea să fie necesar să crești pm.start_servers, sau pm.min/max_spare_servers), pornind 32 copii, sunt 4 inactivi și 59 copii totaleÎncearcă să schimbi parametrul, eroarea nu va dispărea, cum . În acest caz, valoarea pm.min a fost prea mică, iar cum traficul web variază mult și are vârfuri mari și scăderi abrupte, este greu să configurezi adecvat pm dynamic. De obicei, în această situație se folosește pm ondemand, . Dar asta este și mai rău, căci ondemand termină procesele inactive până la zero, când traficul este puțin sau inexistent, și în cele din urmă te vei confrunta tot cu costuri la variația traficului. Dacă, desigur, nu ai stabilit un timp de așteptare uriaș. Și atunci mai bine să folosești pm.static + un număr mare pm.max_requests.
PM dynamic și în special ondemand pot fi de ajutor, dacă ai mai multe pool-uri PHP-FPM. De exemplu, găzduiești mai multe conturi cPanel sau mai multe site-uri web în pool-uri diferite. Am un server unde, să zicem, sunt 100+ conturi cPanel și aproximativ 200 de domenii, iar pm.static sau chiar dynamic nu m-ar salvat. Aici este necesar doar ondemand, căci mai mult de două treimi din site-urile web primesc puțin trafic sau nu primesc deloc, iar cu ondemand toate procesele copilărești se vor prăbuși, ceea ce ne va economisi o mulțime de memorie! Din fericire, dezvoltatorii cPanel au observat asta și au stabilit valoarea implicită ondemand. În trecut, când valoarea implicită era dynamic, PHP-FPM nu era deloc potrivit pentru servere comune încărcate. Mulți foloseau suPHP, deoarece pm dynamic consuma memorie chiar și cu pool-uri inactive și conturi cPanel PHP-FPM. Cel mai probabil, cu un trafic bun, nu vei găzdui pe un server cu un număr mare de pool-uri PHP-FPM (găzduire comună).
Concluzie
Dacă folosești PHP-FPM și traficul tău este serios, managerii de procese ondemand și dynamic pentru PHP-FPM vor limita capacitatea din cauza costurilor inerente. Studiază-ți sistemul și configurează procesele PHP-FPM în conformitate cu capacitatea maximă a serverului. Începe cu pm.max_children în funcție de utilizarea maximă a pm dynamic sau ondemand, și apoi creșteți această valoare până la nivelul în care memoria și procesorul vor funcționa fără suprasarcină excesivă. Veți observa că pm static, având în vedere că totul este stocat în memorie, vârfurile de trafic vor cauza în timp mai puține vârfuri pentru procesor, iar valorile medii ale încărcării serverului și ale procesorului se vor uniformiza. Dimensiunea medie a procesului PHP-FPM depinde de serverul web și necesită configurare manuală, așa că gestiunile de procese mai automatizate sunt dynamic și ondemand — mai populare. Sper că articolul a fost util.
UPD A fost adăugată o diagramă de benchmark . Dacă procesele PHP-FPM sunt în memorie, performanța crește datorită consumului de memorie, unde stau și așteaptă. Găsiți opțiunea optimă pentru dumneavoastră.
Sursa: habr.com
