Artikel Directory
Antallet af samtidige brugere, som en server kan håndtere, afhænger ikke af antallet af kerner, men af hvor meget hukommelse hver proces bruger.
Denne udtalelse lyder måske som en provokation, men det er den mest virkelige og smertefulde oplevelse i drifts- og vedligeholdelsesbranchen.
Hvorfor er hukommelse den største flaskehals?
Mange mennesker ser en VPS med en 8-core CPU og 24 GB hukommelse og tror ubevidst, at de nemt kan køre hundredvis af PHP-FPM-processer.
Men i virkeligheden er RSS-hukommelsesforbruget for en enkelt PHP-proces ofte så højt som 200 MB.
Dette er resultatet opnået gennem faktisk test via kommandolinjen:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
I HestiaCPs komplekse framework og multi-plugin-miljø, især uden OPcache-optimering, er 200 MB normen.
Det betyder, at hukommelsen, ikke CPU'en, er den hårde grænse, der bestemmer maksimal samtidighed.
Anbefalet 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
Parameterberegningslogik og indstillingsgrundlag
| Konfigurationsparametre | Indstillingsværdi | Kerneberegning og opsætningsgrundlag |
|---|---|---|
| pm | dynamic | Dynamisk tilstand muliggør elastisk tilføjelse eller sletning af processer baseret på samtidighedskrav, der afbalancerer svartid og hukommelsesudnyttelse. |
| pm.max_børn | 80 | 24 GB samlet hukommelse minus systemkernen og MySQL/OmforEfter Nginx er der cirka 16 GB tilbage til PHP.16,384 MB / 200 MB ≈ 81.9Hvis den indstilles til 80, kan man fuldstændigt eliminere OOM (Out of Memory) under høj samtidighed. |
| pm.start_servere | 16 | Forvarmning ved opstart er indstillet til det dobbelte af antallet af CPU-kerner (8 kerner × 2 = 16) for at sikre, at tjenesten øjeblikkeligt kan håndtere grundlæggende samtidighed efter genstart. |
| pm.min_reserve_servere | 8 | Indstil CPU-kerneantallet til 8 kerner for at sikre, at nye anmodninger kan besvares når som helst i perioder med lav trafik. |
| pm.max_spare_servere | 24 | Indstil den til 3 gange antallet af CPU-kerner (8 kerner × 3 = 24) for at bevare et moderat antal processer, efter trafikken aftager, for at håndtere små udsving. |
| pm.max_requests | 500 | Hvis en enkelt proces når en stor base på 200 MB, vil en reduktion af antallet af anmodninger til 500 ødelægge og genopbygge processen, hvilket kan rydde op i implicitte hukommelseslækager hurtigere. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers Inaktive processer frigives automatisk og returneres til systemhukommelsen efter 10 sekunder uden anmodninger. |
Vigtige understøttende indstillinger og optimeringsforslag
1. Timeout-mekanisme mod tømmermænd
request_terminate_timeout = 60s Det er nøglen.
Den kan tvangsafbryde processer, der sidder fast på grund af databasedød eller API-blokering fra tredjepart.
I mellemtiden, Nginx's fastcgi_read_timeout Den skal opbevares i mindst 60 sekunder, ellers modtager klienten den for tidligt. 504 Gateway Timeout.
2. Strategier til at overvinde flaskehalse i hukommelsen
Maksimalt 80 samtidige processer betyder, at systemet under ekstreme samtidighedsforhold kan håndtere maksimalt 80 dynamiske HTTP-anmodninger samtidigt.
Hvis du vil forbedre kapaciteten yderligere, bør fokus være på at reducere hukommelsesforbruget pr. proces.
- Aktiver OPcache:eksistere
php.iniMediumkonfigurationopcache.enable=1及opcache.memory_consumption=256Bytecode-caching kan reducere hukommelsesforbruget for en enkelt proces fra 200 MB til 60~100 MB. - Rimelig kontrol over memory_limit：将
php.inimidtmemory_limitBegrænset til128M或256MFor at forhindre individuelle unormale scriptsubegrænsetDet bruger meget hukommelse.
Når hukommelsesforbruget for en enkelt proces falder til 100 MB...pm.max_children Den kan trygt opgraderes til 150 Derudover er samtidighedskapaciteten næsten fordoblet.
Autoritative synspunkter citeret
Ifølge anbefalingerne i den officielle Nginx-dokumentation :
"FastCGI-applikationer bør altid overvåges med timeout-direktiver for at forhindre ressourceudtømning."
(Kilde: Nginx-dokumentation)
Den officielle PHP-manual siger tydeligt:
"pm.max_children definerer det maksimale antal underordnede processer, der kan oprettes. Dette er den vigtigste direktiv."
(Kilde: PHP-FPM-dokumentation)
Disse autoritative synspunkter er perfekt afstemt med vores praksis og beviser, at optimeringslogik ikke kun er baseret på erfaring, men også på standardiserede bedste praksisser.
Konklusion: Mine synspunkter og nøglecitater
I scenarier med høj samtidighed er CPU'en motoren, hukommelsen er brændstoftanken, og PHP-FPM er flådeformidleren.
Uanset hvor kraftig motoren er, vil konvojen ikke køre særlig langt, hvis brændstoftanken ikke er stor nok.
Sande eksperter maksimerer ikke parametrene blindt, men beregner snarere præcist hukommelsesforbruget for hver proces for at undgå både spild og overløb.
Essensen af optimering er at finde den optimale balance med begrænsede ressourcer.
Dette er ikke bare en teknologi, men også en filosofi.
Hold derfor op med at tro, at "antallet af kerner bestemmer alt." Det, der virkelig bestemmer samtidighedsgrænsen, er din kontrol over hukommelsen.
Tag affære og optimer din VPS til dens fulde potentiale, og få mest muligt ud af hver en dråbe hukommelse.
Forhåbentlig vil artiklen "8-core 24GB VPS running out of memory? Extreme tuning of PHP-FPM process pool under HestiaCP", der er delt på Chen Weiliangs blog ( https://www.chenweiliang.com/ ), være nyttig for dig.
Del gerne dette artikellink: https://www.chenweiliang.com/cwl-34509.html