Adresár článkov
Počet súbežných používateľov, ktorých server dokáže spracovať, nezávisí od počtu jadier, ale od toho, koľko pamäte každý proces spotrebuje.
Toto vyhlásenie môže znieť ako provokácia, ale je to najreálnejšia a najbolestivejšia skúsenosť v odvetví prevádzky a údržby.
Prečo je pamäť hlavným úzkym hrdlom?
Mnoho ľudí vidí VPS s 8-jadrovým procesorom a 24 GB pamäte a podvedome si myslia, že na ňom môžu ľahko spustiť stovky PHP-FPM procesov.
V skutočnosti je však využitie pamäte RSS jedným PHP procesom často až 200 MB.
Toto je výsledok získaný skutočným testovaním cez príkazový riadok:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
V komplexnom frameworku a prostredí s viacerými pluginmi HestiaCP , najmä bez optimalizácie OPcache, je 200 MB normou.
To znamená, že pamäť, nie CPU, je pevným limitom, ktorý určuje maximálnu súbežnosť.
Odporúčaný konfiguračný súbor (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
Logika výpočtu parametrov a základ nastavenia
| Konfiguračné parametre | Nastavenie hodnoty | Základ pre výpočet a nastavenie jadra |
|---|---|---|
| pm | dynamic | Dynamický režim umožňuje elastické pridávanie alebo odstraňovanie procesov na základe požiadaviek na súbežnosť, vyvažovanie rýchlosti odozvy a využitia pamäte. |
| pm.max_children | 80 | 24 GB celkovej pamäte bez systémového jadra a MySQL/RedisPo Nginxe zostáva pre PHP približne 16 GB.16,384 MB / 200 MB ≈ 81.9Nastavenie na 80 môže úplne eliminovať OOM (Out of Memory) počas vysokej súbežnosti. |
| pm.start_servers | 16 | Predhrievanie pri spustení je nastavené na dvojnásobok počtu jadier CPU (8 jadier × 2 = 16), aby sa zabezpečilo, že služba dokáže okamžite spracovať základnú súbežnosť po reštarte. |
| pm.min_spare_servers | 8 | Nastavte počet jadier CPU na 8 jadier, aby ste zabezpečili, že na nové požiadavky bude možné reagovať kedykoľvek počas období s nízkou návštevnosťou. |
| pm.max_spare_servers | 24 | Nastavte ho na trojnásobok počtu jadier CPU (8 jadier × 3 = 24), aby ste po poklese prevádzky zachovali mierny počet procesov a zvládli tak mierne výkyvy. |
| pm.max_requests | 500 | Ak jeden proces dosiahne veľkú základňu s veľkosťou 200 MB, zníženie počtu požiadaviek na 500 pred zničením a opätovným zostavením môže rýchlejšie odstrániť implicitné úniky pamäte. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers Nečinné procesy sa automaticky uvoľnia a vrátia do systémovej pamäte po 10 sekundách bez požiadaviek. |
Základné podporné nastavenia a návrhy na optimalizáciu
1. Mechanizmus proti kocovine s časovým limitom
request_terminate_timeout = 60s To je kľúč.
Môže násilne ukončiť procesy, ktoré sú zaseknuté kvôli zablokovaniu databázy alebo blokovaniu API tretích strán.
Medzitým, Nginx fastcgi_read_timeout Musí sa uchovávať aspoň 60 sekúnd, inak ho klient dostane predčasne. 504 Gateway Timeout.
2. Stratégie na prekonanie úzkych miest pamäte
Maximálne 80 súbežných procesov znamená, že za extrémnych podmienok súbežnosti dokáže systém spracovať maximálne 80 dynamických HTTP požiadaviek súčasne.
Ak chcete ďalej zlepšiť kapacitu, mali by ste sa zamerať na zníženie spotreby pamäte na proces.
- Povoliť OPcache: 在
php.iniStredná konfiguráciaopcache.enable=1aopcache.memory_consumption=256Ukladanie bajtkódu do vyrovnávacej pamäte môže znížiť spotrebu pamäte jedným procesom z 200 MB na 60~100 MB. - Rozumná kontrola limitu pamäte：将
php.iniprostrednýmemory_limitObmedzené na128Malebo256MAby sa predišlo jednotlivým abnormálnym skriptomneobmedzenéSpotrebuje veľa pamäte.
Keď klesne využitie pamäte jedným procesom na 100 MB...pm.max_children Dá sa bezpečne upgradovať na 150 Okrem toho sa takmer zdvojnásobila aj schopnosť súbežnosti.
Citované autoritatívne názory
Podľa odporúčaní v oficiálnej dokumentácii Nginx :
„Aplikácie FastCGI by mali byť vždy monitorované pomocou direktív timeout, aby sa predišlo vyčerpaniu zdrojov.“
(Zdroj: Dokumentácia Nginx)
Oficiálna príručka PHP jasne uvádza:
„pm.max_children definuje maximálny počet podradených procesov, ktoré sa majú vytvoriť. Toto je najdôležitejšia direktíva.“
(Zdroj: Dokumentácia PHP-FPM)
Tieto autoritatívne názory sú dokonale v súlade s našimi postupmi a dokazujú, že optimalizačná logika nie je založená len na skúsenostiach, ale aj na štandardizovaných osvedčených postupoch.
Záver: Moje názory a kľúčové citáty
V scenároch s vysokou súbežnosťou je CPU motorom, pamäť palivovou nádržou a PHP-FPM je dispečerom vozového parku.
Bez ohľadu na to, aký výkonný je motor, ak palivová nádrž nie je dostatočne veľká, konvoj nezájde ďaleko.
Skutoční experti slepo nenastavujú parametre na maximum, ale presne vypočítavajú využitie pamäte každým procesom, aby sa predišlo plytvaniu aj pretečeniu.
Podstatou optimalizácie je nájsť optimálnu rovnováhu s obmedzenými zdrojmi.
Nie je to len technológia, ale aj filozofia.
Preto prestaňte veriť, že „počet jadier určuje všetko“. To, čo skutočne určuje limit súbežnosti, je vaša kontrola nad pamäťou.
Podniknite kroky a optimalizujte svoj VPS naplno, aby ste čo najlepšie využili každú kvapku pamäte.
Dúfame, že článok „8-jadrovému 24G VPS dochádza pamäť? Extrémne ladenie PHP-FPM procesného poolu pod HestiaCP“, ktorý bol zdieľaný na blogu Chen Weilianga ( https://www.chenweiliang.com/ ), vám bude užitočný.
Neváhajte a zdieľajte odkaz na tento článok: https://www.chenweiliang.com/cwl-34509.html