Artikkelkatalog
Antall samtidige brukere en server kan håndtere avhenger ikke av hvor mange kjerner den har, men av hvor mye minne hver prosess bruker.
Denne uttalelsen kan høres ut som en provokasjon, men det er den mest reelle og smertefulle opplevelsen i drifts- og vedlikeholdsbransjen.
Hvorfor er minne den viktigste flaskehalsen?
Mange ser en VPS med en 8-kjerners CPU og 24 GB minne og tror ubevisst at de enkelt kan kjøre hundrevis av PHP-FPM-prosesser.
I virkeligheten er imidlertid RSS-minnebruken til en enkelt PHP-prosess ofte så høy som 200 MB.
Dette er resultatet som ble oppnådd gjennom faktisk testing via kommandolinjen:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
I HestiaCPs komplekse rammeverk og miljø med flere plugins, spesielt uten OPcache-optimalisering, er 200 MB normen.
Dette betyr at minne, ikke CPU, er den harde grensen som bestemmer maksimal samtidighet.
Anbefalt konfigurasjonsfil (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
Parameterberegningslogikk og innstillingsgrunnlag
| Konfigurasjonsparametere | Innstillingsverdi | Kjerneberegning og oppsettsgrunnlag |
|---|---|---|
| pm | dynamic | Dynamisk modus tillater elastisk tillegg eller sletting av prosesser basert på samtidighetskrav, og balanserer responshastighet og minneutnyttelse. |
| pm.max_barn | 80 | 24 GB totalt minne minus systemkjernen og MySQL/RedisEtter Nginx er det omtrent 16 GB igjen til PHP.16,384 MB / 200 MB ≈ 81.9Hvis du setter den til 80, kan du fullstendig eliminere OOM (Out of Memory) under høy samtidighet. |
| pm.start_servere | 16 | Forvarming ved oppstart er satt til dobbelt så mange CPU-kjerner (8 kjerner × 2 = 16) for å sikre at tjenesten umiddelbart kan håndtere grunnleggende samtidighet etter omstart. |
| pm.min_spare_servere | 8 | Sett CPU-kjerneantallet til 8 kjerner for å sikre at nye forespørsler kan besvares når som helst i perioder med lav trafikk. |
| pm.max_spare_servere | 24 | Sett den til 3 ganger antallet CPU-kjerner (8 kjerner × 3 = 24) for å beholde et moderat antall prosesser etter at trafikken avtar, for å håndtere milde svingninger. |
| pm.max_requests | 500 | Hvis en enkelt prosess når en stor base på 200 MB, vil en reduksjon av antall forespørsler til 500 ødelegge og gjenoppbygge prosessen, noe som kan rydde opp i implisitte minnelekkasjer raskere. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers Inaktive prosesser frigjøres automatisk og returneres til systemminnet etter 10 sekunder uten forespørsler. |
Viktige støtteinnstillinger og optimaliseringsforslag
1. Timeout-mekanisme mot bakrus
request_terminate_timeout = 60s Det er nøkkelen.
Den kan tvangsinnstille prosesser som står fast på grunn av databasevranglås eller API-blokkering fra tredjepart.
I mellomtiden, Nginx sin fastcgi_read_timeout Den må oppbevares i minst 60 sekunder, ellers vil klienten motta den for tidlig. 504 Gateway Timeout.
2. Strategier for å overvinne flaskehalser i minnet
Maksimalt 80 samtidige prosesser betyr at systemet under ekstreme samtidighetsforhold kan håndtere maksimalt 80 dynamiske HTTP-forespørsler samtidig.
Hvis du vil forbedre kapasiteten ytterligere, bør fokuset være på å redusere minnebruken per prosess.
- Aktiver OPcache: 在
php.iniMedium konfigurasjonopcache.enable=1ogopcache.memory_consumption=256Bytekode-caching kan redusere minnebruken til en enkelt prosess fra 200 MB til 60–100 MB. - Rimelig kontroll over memory_limit：将
php.inimidtenmemory_limitBegrenset til128Meller256MFor å forhindre individuelle unormale skriptubegrensetDet bruker mye minne.
Når minnebruken til en enkelt prosess synker til 100 MB ...pm.max_children Den kan trygt oppgraderes til 150 I tillegg har samtidighetskapasiteten nesten doblet seg.
Autoritative synspunkter sitert
I følge anbefalingene i den offisielle Nginx-dokumentasjonen :
"FastCGI-applikasjoner bør alltid overvåkes med tidsavbruddsdirektiver for å forhindre ressursutmattelse."
(Kilde: Nginx-dokumentasjon)
Den offisielle PHP-manualen sier tydelig:
"pm.max_children definerer det maksimale antallet barneprosesser som kan opprettes. Dette er det viktigste direktivet."
(Kilde: PHP-FPM-dokumentasjon)
Disse autoritative synspunktene er perfekt i tråd med vår praksis, og beviser at optimaliseringslogikk ikke bare er basert på erfaring, men også på standardiserte beste praksiser.
Konklusjon: Mine synspunkter og viktige sitater
I scenarier med høy samtidighet er CPU-en motoren, minnet er drivstofftanken, og PHP-FPM er flåteekspeditøren.
Uansett hvor kraftig motoren er, vil ikke konvoien kjøre særlig langt hvis drivstofftanken ikke er stor nok.
Ekte eksperter maksimerer ikke parameterne blindt, men beregner heller presist minnebruken til hver prosess for å unngå både sløsing og overløp.
Kjernen i optimalisering er å finne den optimale balansen med begrensede ressurser.
Dette er ikke bare en teknologi, men også en filosofi.
Slutt derfor å tro at «antall kjerner bestemmer alt». Det som virkelig bestemmer samtidighetsgrensen er din kontroll over minnet.
Ta grep og optimaliser VPS-en din til sitt fulle potensial, og få mest mulig ut av hver dråpe minne.
Forhåpentligvis vil artikkelen «8-kjerners 24 GB VPS som går tom for minne? Ekstrem tuning av PHP-FPM-prosesspoolen under HestiaCP» som er delt på Chen Weiliangs blogg ( https://www.chenweiliang.com/ ) være nyttig for deg.
Del gjerne lenken til denne artikkelen: https://www.chenweiliang.com/cwl-34509.html