Directorio de artigos
O número de usuarios simultáneos que pode xestionar un servidor non depende de cantos núcleos teña, senón de canta memoria consume cada proceso.
Esta afirmación pode soar a provocación, pero é a experiencia máis real e dolorosa na industria de operacións e mantemento.
Por que é a memoria o principal obstáculo?
Moita xente ve un VPS cunha CPU de 8 núcleos e 24 GB de memoria e subconscientemente pensa que pode executar facilmente centos de procesos PHP-FPM.
Non obstante, en realidade, o uso de memoria RSS dun único proceso PHP adoita chegar aos 200 MB.
Este é o resultado obtido mediante probas reais a través da liña de comandos:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
No complexo marco de traballo e no entorno de varios complementos de HestiaCP , especialmente sen a optimización de OPcache, 200 MB son a norma.
Isto significa que a memoria, e non a CPU, é o límite estrito que determina a máxima concorrencia.
Ficheiro de configuración recomendado (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óxica de cálculo de parámetros e base de configuración
| Parámetros de configuración | Valor de configuración | Cálculo do núcleo e base de configuración |
|---|---|---|
| pm | dynamic | O modo dinámico permite a adición ou eliminación elástica de procesos segundo os requisitos de concorrencia, equilibrando a velocidade de resposta e o uso da memoria. |
| pm.max_nenos | 80 | 24 GB de memoria total sen o núcleo do sistema e MySQL/RedisDespois de Nginx, quedan aproximadamente 16 GB para PHP.16,384 MB / 200 MB ≈ 81.9Definilo en 80 pode eliminar por completo a OOM (Fuga de memoria) durante a alta concorrencia. |
| pm.start_servers | 16 | O prequecemento ao inicio está configurado no dobre do número de núcleos de CPU (8 núcleos × 2 = 16) para garantir que o servizo poida xestionar instantaneamente a simultaneidade básica despois de reiniciar. |
| pm.min_spare_servers | 8 | Define o número de núcleos da CPU en 8 núcleos para garantir que se poida responder ás novas solicitudes en calquera momento durante os períodos de baixo tráfico. |
| pm.max_spare_servers | 24 | Axusteo a 3 veces o número de núcleos de CPU (8 núcleos × 3 = 24) para manter un número moderado de procesos despois de que o tráfico diminúa, co fin de xestionar flutuacións suaves. |
| pm.max_requests | 500 | Se un único proceso alcanza unha base grande de 200 MB, reducir o número de solicitudes a 500 antes de destruílo e reconstruílo pode limpar as fugas de memoria implícitas máis rápido. |
| pm.process_idle_timeout | 10s | Superando min_spare_servers Os procesos inactivos libéranse automaticamente e devólvense á memoria do sistema despois de 10 segundos sen solicitudes. |
Configuración de apoio esenciais e suxestións de optimización
1. Mecanismo antiresaca con tempo límite
request_terminate_timeout = 60s Esa é a clave.
Pode rescindir por forza os procesos que están atascados debido a un punto morto na base de datos ou a un bloqueo da API de terceiros.
Mentres tanto, de Nginx fastcgi_read_timeout Debe gardarse polo menos 60 segundos, se non, o cliente recibirao prematuramente. 504 Gateway Timeout.
2. Estratexias para superar os atrancos de memoria
Un máximo de 80 procesos simultáneos significa que, en condicións de concorrencia extremas, o sistema pode xestionar un máximo de 80 solicitudes HTTP dinámicas simultaneamente.
Se queres mellorar aínda máis a capacidade, debes centrarte en reducir o uso de memoria por proceso.
- Activa OPcache: En
php.iniConfiguración mediaopcache.enable=1eopcache.memory_consumption=256O almacenamento en caché de bytecode pode reducir o uso de memoria dun único proceso de 200 MB a 60~100 MB. - Control razoable de memory_limitWill
php.inimediomemory_limitLimitado a128M或256MPara evitar scripts individuais anormaisilimitadoConsome moita memoria.
Unha vez que o uso de memoria dun só proceso baixa a 100 MB...pm.max_children Pódese actualizar con seguridade a 150 Ademais, a capacidade de concorrencia case se duplicou.
Puntos de vista autorizados citados
Segundo as recomendacións da documentación oficial de Nginx :
"As aplicacións FastCGI sempre deberían monitorizarse con directivas de tempo de espera para evitar o esgotamento dos recursos."
(Fonte: Documentación de Nginx)
O manual oficial de PHP indica claramente:
"pm.max_children define o número máximo de procesos fillos que se van crear. Esta é a directiva máis importante."
(Fonte: Documentación de PHP-FPM)
Estas opinións autorizadas están perfectamente aliñadas coas nosas prácticas, o que demostra que a lóxica de optimización non só se basea na experiencia, senón tamén nas mellores prácticas estandarizadas.
Conclusión: Os meus puntos de vista e citas clave
En escenarios de alta concorrencia, a CPU é o motor, a memoria é o depósito de combustible e PHP-FPM é o despachador da frota.
Non importa a potencia do motor, se o depósito de combustible non é o suficientemente grande, o convoi non chegará moi lonxe.
Os verdadeiros expertos non maximizan os parámetros cegamente, senón que calculan con precisión o uso de memoria de cada proceso para evitar tanto o desperdicio como o desbordamento.
A esencia da optimización é atopar o equilibrio óptimo con recursos limitados.
Isto non é só unha tecnoloxía, senón tamén unha filosofía.
Polo tanto, deixa de crer que "o número de núcleos o determina todo". O que realmente determina o límite de concorrencia é o teu control sobre a memoria.
Actúa e optimiza o teu VPS ao máximo, aproveitando ao máximo cada gota de memoria.
Esperemos que o artigo "VPS de 8 núcleos e 24 GB quedándose sen memoria? Axuste extremo do grupo de procesos PHP-FPM baixo HestiaCP" compartido no blog de Chen Weiliang ( https://www.chenweiliang.com/ ) che sexa útil.
Non dubides en compartir a ligazón deste artigo: https://www.chenweiliang.com/cwl-34509.html