Artikel Verzeechnes
D'Zuel vun de gläichzäitege Benotzer, déi e Server handhabe kann, hänkt net dovun of, wéi vill Kären en huet, mä dovun, wéi vill Speicher all Prozess verbraucht.
Dës Ausso kéint wéi eng Provokatioun kléngen, awer et ass déi realisteschst an penibelst Erfahrung an der Operatiouns- a Maintenancebranche.
Firwat ass d'Erënnerung de Schlëssel-Engpass?
Vill Leit gesinn e VPS mat enger 8-Core CPU an 24GB Späicher a mengen ënnerbewosst, datt se ouni Problemer Honnerte vu PHP-FPM Prozesser ausféiere kënnen.
Awer a Wierklechkeet ass den RSS-Speicherverbrauch vun engem eenzege PHP-Prozess dacks bis zu 200 MB.
Dëst ass d'Resultat, dat duerch tatsächlech Tester iwwer d'Kommandozeil kritt gouf:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
Am komplexe Framework an der Multi-Plugin-Ëmfeld vun HestiaCP , besonnesch ouni OPcache-Optimiséierung, sinn 200 MB d'Norm.
Dëst bedeit datt de Speicher, net d'CPU, déi haart Limit ass, déi maximal Konkurrenzitéit bestëmmt.
Recommandéiert Konfiguratiounsdatei (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
Logik vun der Parameterberechnung an d'Astellungsbasis
| Configuratioun Parameteren | Wäert astellen | Kärberechnung a Basis fir d'Astellung |
|---|---|---|
| pm | dynamic | Den dynamesche Modus erlaabt d'elastesch Zousätz oder d'Läschung vu Prozesser baséiert op de Konkurrenzufuerderungen, andeems d'Reaktiounsgeschwindegkeet an d'Speicherauslastung ausbalancéiert ginn. |
| pm.max_Kanner | 80 | 24 GB Gesamtspeicher ouni de Systemkernel an MySQL/RedisNo Nginx bleiwen ongeféier 16GB fir PHP iwwreg.16,384 MB / 200 MB ≈ 81.9Wann Dir et op 80 setzt, kann OOM (Out of Memory) bei héijer Concurrency komplett eliminéiert ginn. |
| pm.start_servers | 16 | D'Virhëtzung beim Start ass op duebel sou vill CPU-Kären agestallt (8 Kären × 2 = 16), fir sécherzestellen, datt de Service direkt no dem Restart mat Basis-Konkurrenzdenken ëmgoe kann. |
| pm.min_spare_servers | 8 | Setzt d'CPU-Kärzuel op 8 Kären, fir sécherzestellen, datt op nei Ufroen zu all Moment a Perioden mat wéineg Traffic reagéiert ka ginn. |
| pm.max_spare_servers | 24 | Setzt et op d'dräi Mol sou vill CPU-Kären (8 Kären × 3 = 24), fir eng moderéiert Zuel vu Prozesser ze behalen, nodeems den Traffic zréckgaangen ass, fir mat liichten Schwankungen eens ze ginn. |
| pm.max_requests | 500 | Wann een eenzege Prozess eng grouss Basis vun 200 MB erreecht, wäert d'Reduktioun vun der Unzuel vun Ufroen op 500 de Prozess zerstéieren an nei opbauen, wat implizit Speicherlecks méi séier botze kann. |
| pm.process_idle_timeout | 10s | Iwwerschreiden min_spare_servers Inaktiv Prozesser ginn automatesch fräigelooss a ginn no 10 Sekonnen ouni Ufroen an de Systemspeicher zréckgefouert. |
Essentiell Ënnerstëtzungsastellungen an Optimiséierungsvirschléi
1. Timeout-Anti-Kater-Mechanismus
request_terminate_timeout = 60s Dat ass de Schlëssel.
Et kann Prozesser gezwongen ofbriechen, déi wéinst engem Datebank-Deadlock oder enger API-Blockéierung vun Drëttubidder festgehale sinn.
Mëttlerweil, Nginx säin fastcgi_read_timeout Et muss mindestens 60 Sekonnen gespäichert ginn, soss kritt de Client et virzäiteg. 504 Gateway Timeout.
2. Strategien fir Gedächtnisproblemer ze iwwerwannen
Maximal 80 gläichzäiteg Prozesser bedeit, datt de System ënner extremen Concurrency-Konditiounen maximal 80 dynamesch HTTP-Ufroen gläichzäiteg veraarbechte kann.
Wann Dir d'Kapazitéit weider verbessere wëllt, sollt de Fokus op der Reduktioun vum Speicherverbrauch pro Prozess leien.
- OPcache aktivéieren: 在
php.iniMëttelkonfiguratiounopcache.enable=1anopcache.memory_consumption=256Bytecode-Caching kann de Speicherverbrauch vun engem eenzege Prozess vun 200 MB op 60~100 MB reduzéieren. - Vernünfteg Kontroll vum Memory_limit:Wëllen
php.iniMëttmemory_limitLimitéiert op128MËff256MFir individuell anormal Skripter ze verhënnerenonlimitéiertEt verbraucht vill Erënnerung.
Soubal de Speicherverbrauch vun engem eenzege Prozess op 100 MB fällt...pm.max_children Et kann sécher opgebaut ginn 150 Zousätzlech huet sech d'Konkurrenzfäegkeet bal verduebelt.
Autoritär Meenungen, déi zitéiert goufen
No den Empfehlungen an der offizieller Nginx-Dokumentatioun :
"FastCGI Applikatioune sollten ëmmer mat Timeout-Direktiven iwwerwaacht ginn, fir Ressourcen ze vermeiden."
(Quell: Nginx Dokumenter)
Am offiziellen PHP-Handbuch steet et kloer:
"pm.max_children definéiert déi maximal Zuel vun Ënnerprozesser, déi erstallt solle ginn. Dëst ass déi wichtegst Direktiv."
(Quell: PHP-FPM Dokumentatioun)
Dës autoritär Meenungen stëmmen perfekt mat eise Praktiken iwwereneen a beweisen, datt d'Optimiséierungslogik net nëmmen op Erfahrung baséiert, mä och op standardiséierte Best Practices.
Conclusioun: Meng Meenungen a Schlësselzitater
A Szenarie mat héijer Konkurrenzzäit ass d'CPU de Motor, de Speicher den Tank an de PHP-FPM ass den Flottendispatcher.
Egal wéi staark de Motor ass, wann den Tank net grouss genuch ass, geet de Konvoi net wäit.
Richteg Experten limitéieren d'Parameteren net blann, mä berechnen präzis de Speicherverbrauch vun all Prozess, fir souwuel Verschwendung wéi och Iwwerflut ze vermeiden.
D'Essenz vun der Optimiséierung ass et, dat optimalt Gläichgewiicht mat limitéierten Ressourcen ze fannen.
Dëst ass net nëmmen eng Technologie, mä och eng Philosophie.
Dofir, gleeft net méi, datt "d'Zuel vun de Kären alles bestëmmt". Wat wierklech d'Konkurrenzlimit bestëmmt, ass Är Kontroll iwwer de Speicher.
Maacht eppes fir Äre VPS optimal ze optimiséieren, andeems Dir all Drëps Speicher optimal notzt.
Hoffentlech ass den Artikel "8-Core 24GB VPS running out of memory? Extreme tuning of PHP-FPM process pool under HestiaCP", deen um Blog vum Chen Weiliang ( https://www.chenweiliang.com/ ) gedeelt gouf, Iech hëllefräich.
Deelt gären de Link vun dësem Artikel: https://www.chenweiliang.com/cwl-34509.html