Artikelkatalog
Antalet samtidiga användare som en server kan hantera beror inte på hur många kärnor den har, utan på hur mycket minne varje process förbrukar.
Detta uttalande kan låta som en provokation, men det är den mest verkliga och smärtsamma upplevelsen inom drift- och underhållsbranschen.
Varför är minnet den största flaskhalsen?
Många ser en VPS med en 8-kärnig processor och 24 GB minne och tror omedvetet att de enkelt kan köra hundratals PHP-FPM-processer.
Men i verkligheten är RSS-minnesanvändningen för en enskild PHP-process ofta så hög som 200 MB.
Detta är resultatet som erhölls genom faktisk testning via kommandoraden:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
I HestiaCP :s komplexa ramverk och miljö med flera plugins, särskilt utan OPcache-optimering, är 200 MB normen.
Det betyder att minne, inte CPU, är den hårda gränsen som avgör maximal samtidighet.
Rekommenderad konfigurationsfil (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
Parameterberäkningslogik och inställningsgrund
| Konfigurationsparametrar | Inställningsvärde | Kärnberäkning och uppställningsgrund |
|---|---|---|
| pm | dynamic | Dynamiskt läge möjliggör elastisk tillägg eller borttagning av processer baserat på samtidighetskrav, vilket balanserar svarshastighet och minnesutnyttjande. |
| pm.max_barn | 80 | 24 GB totalt minne minus systemkärnan och MySQL/RedisEfter Nginx återstår ungefär 16 GB för PHP.16,384 MB / 200 MB ≈ 81.9Att ställa in den på 80 kan helt eliminera OOM (Out of Memory) vid hög samtidighet. |
| pm.start_servers | 16 | Förvärmning vid start är inställd på dubbelt så många CPU-kärnor (8 kärnor × 2 = 16) för att säkerställa att tjänsten direkt kan hantera grundläggande samtidighet efter omstart. |
| pm.min_spare_servrar | 8 | Ställ in antalet CPU-kärnor till 8 kärnor för att säkerställa att nya förfrågningar kan besvaras när som helst under perioder med låg trafik. |
| pm.max_spare_servrar | 24 | Ställ in den på 3 gånger antalet CPU-kärnor (8 kärnor × 3 = 24) för att behålla ett måttligt antal processer efter att trafiken minskat, för att hantera lätta fluktuationer. |
| pm.max_requests | 500 | Om en enskild process når en stor bas på 200 MB, kan en minskning av antalet förfrågningar till 500 innan förstöring och återuppbyggnad rensa upp implicita minnesläckor snabbare. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers Inaktiva processer släpps automatiskt och återförs till systemminnet efter 10 sekunder utan förfrågningar. |
Viktiga stödjande inställningar och optimeringsförslag
1. Timeout-mekanism mot baksmälla
request_terminate_timeout = 60s Det är nyckeln.
Den kan tvinga fram ett avbrott i processer som har fastnat på grund av ett dödläge i databasen eller blockering av tredjeparts-API:er.
Samtidigt, Nginx fastcgi_read_timeout Den måste sparas i minst 60 sekunder, annars får klienten den i förtid. 504 Gateway Timeout.
2. Strategier för att övervinna minnesflaskhalsar
Maximalt 80 samtidiga processer innebär att systemet under extrema samtidighetsförhållanden kan hantera maximalt 80 dynamiska HTTP-förfrågningar samtidigt.
Om du vill förbättra kapaciteten ytterligare bör fokus ligga på att minska minnesanvändningen per process.
- Aktivera OPcache：在
php.iniMediumkonfigurationopcache.enable=1Ochopcache.memory_consumption=256Bytekodscachning kan minska minnesanvändningen för en enskild process från 200 MB till 60~100 MB. - Rimlig kontroll över memory_limit：将
php.inimittenmemory_limitBegränsad till128Meller256MFör att förhindra enskilda onormala skriptobegränsatDet förbrukar mycket minne.
När minnesanvändningen för en enskild process sjunker till 100 MB...pm.max_children Den kan säkert uppgraderas till 150 Dessutom har samtidighetskapaciteten nästan fördubblats.
Auktoritativa synpunkter som citeras
Enligt rekommendationerna i den officiella Nginx-dokumentationen :
"FastCGI-applikationer bör alltid övervakas med timeout-direktiv för att förhindra resursutmattning."
(Källa: Nginx-dokumentation)
Den officiella PHP-manualen anger tydligt:
"pm.max_children definierar det maximala antalet underprocesser som ska skapas. Detta är det viktigaste direktivet."
(Källa: PHP-FPM-dokumentation)
Dessa auktoritativa åsikter är perfekt i linje med våra metoder och bevisar att optimeringslogik inte bara är baserad på erfarenhet, utan också på standardiserade bästa praxis.
Slutsats: Mina synpunkter och viktiga citat
I scenarier med hög samtidighet är processorn motorn, minnet bränsletanken och PHP-FPM är flottans ansvarige.
Oavsett hur kraftfull motorn är, om bränsletanken inte är tillräckligt stor, kommer konvojen inte att gå särskilt långt.
Riktiga experter maximerar inte parametrarna blint, utan beräknar snarare exakt minnesanvändningen för varje process för att undvika både slöseri och överflöd.
Kärnan i optimering är att hitta den optimala balansen med begränsade resurser.
Detta är inte bara en teknologi, utan också en filosofi.
Sluta därför tro att "antalet kärnor avgör allt." Det som verkligen avgör samtidighetsgränsen är din kontroll över minnet.
Vidta åtgärder och optimera din VPS till dess fulla potential, och få ut det mesta av varje droppe minne.
Förhoppningsvis kommer artikeln "8-core 24GB VPS running out of memory? Extreme tuning of PHP-FPM process pool under HestiaCP" som delas på Chen Weiliangs blogg ( https://www.chenweiliang.com/ ) att vara till hjälp för dig.
Dela gärna länken till den här artikeln: https://www.chenweiliang.com/cwl-34509.html