Directori d'articles
El nombre d'usuaris simultanis que pot gestionar un servidor no depèn de quants nuclis té, sinó de quanta memòria consumeix cada procés.
Aquesta afirmació pot semblar una provocació, però és l'experiència més real i dolorosa de la indústria d'operacions i manteniment.
Per què la memòria és el principal coll d'ampolla?
Molta gent veu un VPS amb una CPU de 8 nuclis i 24 GB de memòria i inconscientment pensa que pot executar fàcilment centenars de processos PHP-FPM.
No obstant això, en realitat, l'ús de memòria RSS d'un sol procés PHP sovint arriba als 200 MB.
Aquest és el resultat obtingut mitjançant proves reals via línia d'ordres:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
En el complex marc de treball i l'entorn multi-plugin d' HestiaCP , especialment sense l'optimització d'OPcache, 200 MB són la norma.
Això significa que la memòria, i no la CPU, és el límit estricte que determina la màxima concurrència.
Fitxer de configuració recomanat (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
Lògica de càlcul de paràmetres i base de configuració
| Paràmetres de configuració | Valor de configuració | Càlcul bàsic i base de configuració |
|---|---|---|
| pm | dynamic | El mode dinàmic permet l'addició o eliminació elàstica de processos en funció dels requisits de concurrència, equilibrant la velocitat de resposta i l'ús de memòria. |
| pm.max_nens | 80 | 24 GB de memòria total menys el nucli del sistema i MySQL/RedisDesprés de Nginx, queden aproximadament 16 GB per a PHP.16,384 MB / 200 MB ≈ 81.9Si ho estableixes a 80, pots eliminar completament l'OOM (Out of Memory) durant una concurrència alta. |
| pm.start_servers | 16 | El preescalfament a l'inici està definit al doble del nombre de nuclis de CPU (8 nuclis × 2 = 16) per garantir que el servei pugui gestionar instantàniament la concurrència bàsica després de reiniciar. |
| pm.min_spare_servers | 8 | Establiu el recompte de nuclis de la CPU a 8 nuclis per garantir que es pugui respondre a les noves sol·licituds en qualsevol moment durant els períodes de baix trànsit. |
| pm.max_spare_servers | 24 | Establiu-ho a 3 vegades el nombre de nuclis de CPU (8 nuclis × 3 = 24) per conservar un nombre moderat de processos després que el trànsit disminueixi, per tal de gestionar fluctuacions suaus. |
| pm.max_requests | 500 | Si un sol procés arriba a una base gran de 200 MB, reduir el nombre de sol·licituds a 500 abans de destruir-lo i reconstruir-lo pot netejar les fuites de memòria implícites més ràpidament. |
| pm.process_idle_timeout | 10s | Superant min_spare_servers Els processos inactius s'alliberen automàticament i es retornen a la memòria del sistema després de 10 segons sense sol·licituds. |
Configuració de suport essencial i suggeriments d'optimització
1. Mecanisme anti-ressaca amb temps d'espera
request_terminate_timeout = 60s Aquesta és la clau.
Pot tancar per la força els processos que estan bloquejats a causa d'un bloqueig de la base de dades o d'un bloqueig d'API de tercers.
Mentrestant, Nginx fastcgi_read_timeout S'ha de conservar almenys 60 segons, altrament el client el rebrà prematurament. 504 Gateway Timeout.
2. Estratègies per superar els colls d'ampolla de memòria
Un màxim de 80 processos simultanis significa que, en condicions de concurrència extremes, el sistema pot gestionar un màxim de 80 sol·licituds HTTP dinàmiques simultàniament.
Si voleu millorar encara més la capacitat, us heu de centrar en reduir l'ús de memòria per procés.
- Activa OPcache: En
php.iniConfiguració mitjanaopcache.enable=1iopcache.memory_consumption=256L'emmagatzematge en memòria cau de bytecode pot reduir l'ús de memòria d'un sol procés de 200 MB a 60~100 MB. - Control raonable de memory_limit：将
php.inimigmemory_limitLimitat a128M或256MPer evitar scripts anormals individualsil·limitatConsumeix molta memòria.
Un cop l'ús de memòria d'un sol procés baixa a 100 MB...pm.max_children Es pot actualitzar amb seguretat a 150 A més, la capacitat de concurrència gairebé s'ha duplicat.
Punts de vista autoritzats citats
Segons les recomanacions de la documentació oficial de Nginx :
"Les aplicacions FastCGI sempre s'han de monitoritzar amb directives de temps d'espera per evitar l'esgotament dels recursos."
(Font: Documentació de Nginx)
El manual oficial de PHP ho diu clarament:
"pm.max_children defineix el nombre màxim de processos fills que es crearan. Aquesta és la directiva més important."
(Font: Documentació de PHP-FPM)
Aquests punts de vista autoritzats estan perfectament alineats amb les nostres pràctiques, cosa que demostra que la lògica d'optimització no només es basa en l'experiència, sinó també en les millors pràctiques estandarditzades.
Conclusió: els meus punts de vista i cites clau
En escenaris d'alta concurrència, la CPU és el motor, la memòria és el dipòsit de combustible i PHP-FPM és el despatxador de la flota.
Per molt potent que sigui el motor, si el dipòsit de combustible no és prou gran, el comboi no arribarà gaire lluny.
Els veritables experts no maximitzen els paràmetres a cegues, sinó que calculen amb precisió l'ús de memòria de cada procés per evitar tant el malbaratament com el desbordament.
L'essència de l'optimització és trobar l'equilibri òptim amb recursos limitats.
Això no és només una tecnologia, sinó també una filosofia.
Per tant, deixeu de creure que "el nombre de nuclis ho determina tot". El que realment determina el límit de concurrència és el vostre control sobre la memòria.
Actua i optimitza el teu VPS al màxim, aprofitant al màxim cada gota de memòria.
Esperem que l'article "VPS de 8 nuclis i 24 GB quedant-se sense memòria? Ajust extrem del grup de processos PHP-FPM sota HestiaCP" compartit al blog de Chen Weiliang ( https://www.chenweiliang.com/ ) us sigui útil.
No dubteu a compartir l'enllaç d'aquest article: https://www.chenweiliang.com/cwl-34509.html