Artigo Diretório
O número de usuários simultâneos que um servidor pode suportar não depende de quantos núcleos ele possui, mas sim de quanta memória cada processo consome.
Essa afirmação pode soar como uma provocação, mas representa a experiência mais real e dolorosa no setor de operações e manutenção.
Por que a memória é o principal gargalo?
Muitas pessoas veem um VPS com uma CPU de 8 núcleos e 24 GB de memória e, subconscientemente, pensam que podem executar facilmente centenas de processos PHP-FPM.
No entanto, na realidade, o uso de memória RSS de um único processo PHP costuma ser tão alto quanto 200 MB.
Este é o resultado obtido através de testes reais via linha de comando:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
No ambiente complexo e com múltiplos plugins do HestiaCP , especialmente sem a otimização do OPcache, 200 MB é o padrão.
Isso significa que a memória, e não a CPU, é o limite máximo que determina a concorrência.
Arquivo de configuração 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ógica de cálculo de parâmetros e base de configuração
| Parâmetros de configuração | Definir valor | Base principal para cálculos e configuração |
|---|---|---|
| pm | dynamic | O modo dinâmico permite a adição ou remoção elástica de processos com base nos requisitos de concorrência, equilibrando a velocidade de resposta e a utilização da memória. |
| pm.max_children | 80 | 24 GB de memória total, excluindo o kernel do sistema e MySQL/RedisApós o Nginx, restam aproximadamente 16 GB para o PHP.16,384 MB / 200 MB ≈ 81.9Definir esse valor para 80 pode eliminar completamente o erro OOM (Out of Memory - Falta de Memória) durante períodos de alta concorrência. |
| pm.iniciar_servidores | 16 | O pré-aquecimento na inicialização está configurado para o dobro do número de núcleos da CPU (8 núcleos × 2 = 16) para garantir que o serviço possa lidar instantaneamente com a concorrência básica após a reinicialização. |
| pm.min_servidores_reserva | 8 | Defina o número de núcleos da CPU para 8 para garantir que novas solicitações possam ser atendidas a qualquer momento durante períodos de baixo tráfego. |
| pm.max_servidores_reservados | 24 | Defina-o para 3 vezes o número de núcleos da CPU (8 núcleos × 3 = 24) para manter um número moderado de processos após a redução do tráfego, a fim de lidar com flutuações leves. |
| pm.max_requests | 500 | Se um único processo atingir uma base grande de 200 MB, reduzir o número de solicitações para 500 antes de destruir e reconstruir o processo pode eliminar vazamentos de memória implícitos mais rapidamente. |
| pm.process_idle_timeout | 10s | Excedendo min_spare_servers Os processos ociosos são liberados automaticamente e retornam à memória do sistema após 10 segundos sem solicitações. |
Configurações de suporte essenciais e sugestões de otimização
1. Mecanismo anti-ressaca com tempo limite
request_terminate_timeout = 60s Essa é a chave.
Ele pode encerrar à força processos que estejam travados devido a impasse no banco de dados ou bloqueio por API de terceiros.
Entretanto, o Nginx fastcgi_read_timeout Deve ser mantido por pelo menos 60 segundos, caso contrário o cliente o receberá prematuramente. 504 Gateway Timeout.
2. Estratégias para superar gargalos de memória
Um máximo de 80 processos simultâneos significa que, em condições extremas de concorrência, o sistema pode lidar com um máximo de 80 solicitações HTTP dinâmicas simultaneamente.
Se você deseja aumentar ainda mais a capacidade, o foco deve ser na redução do uso de memória por processo.
- Habilitar OPcache： 在
php.iniConfiguração médiaopcache.enable=1Eopcache.memory_consumption=256O cache de bytecode pode reduzir o uso de memória de um único processo de 200 MB para 60 a 100 MB. - Controle razoável do limite de memória:Vai
php.inimeiomemory_limitLimitado a128M或256MPara evitar scripts anormais individuais无限Consome muita memória.
Assim que o uso de memória de um único processo cair para 100 MB...pm.max_children Pode ser atualizado com segurança para 150 Além disso, a capacidade de processamento simultâneo praticamente dobrou.
Pontos de vista de autoridades citados
De acordo com as recomendações da documentação oficial do Nginx :
"As aplicações FastCGI devem sempre ser monitoradas com diretivas de tempo limite para evitar o esgotamento de recursos."
(Fonte: Documentação do Nginx)
O manual oficial do PHP afirma claramente:
"pm.max_children define o número máximo de processos filhos a serem criados. Esta é a diretiva mais importante."
(Fonte: Documentação do PHP-FPM)
Essas visões de especialistas estão perfeitamente alinhadas com nossas práticas, comprovando que a lógica de otimização não se baseia apenas na experiência, mas também em práticas recomendadas padronizadas.
Conclusão: Meus pontos de vista e citações principais
Em cenários de alta concorrência, a CPU é o motor, a memória é o tanque de combustível e o PHP-FPM é o despachante da frota.
Por mais potente que seja o motor, se o tanque de combustível não for grande o suficiente, o comboio não irá muito longe.
Os verdadeiros especialistas não maximizam os parâmetros indiscriminadamente, mas sim calculam com precisão o uso de memória de cada processo para evitar desperdício e estouro de memória.
A essência da otimização é encontrar o equilíbrio ideal com recursos limitados.
Isso não é apenas uma tecnologia, mas também uma filosofia.
Portanto, pare de acreditar que "o número de núcleos determina tudo". O que realmente determina o limite de concorrência é o seu controle sobre a memória.
Tome medidas e otimize seu VPS ao máximo, aproveitando cada gota de memória.
Esperamos que o artigo "VPS de 8 núcleos e 24 GB ficando sem memória? Ajuste extremo do pool de processos PHP-FPM no HestiaCP", compartilhado no blog de Chen Weiliang ( https://www.chenweiliang.com/ ), seja útil para você.
Sinta-se à vontade para compartilhar o link deste artigo: https://www.chenweiliang.com/cwl-34509.html