Uma versão não editada deste artigo foi publicada originalmente em e publicado aqui com sua permissão .
Direi resumidamente a melhor forma de configurar o PHP-FPM para aumentar o rendimento, reduzir a latência e usar CPU e memória de forma mais consistente. Por padrão, a linha PM (gerenciador de processos) no PHP-FPM é dinâmico, e se você não tiver memória suficiente, é melhor instalar ondemand. Vamos comparar 2 opções de controle baseadas na documentação do php.net e ver como meu favorito difere delas estático pm para tráfego de alto volume:
pm = dinâmico — o número de processos filhos é configurado dinamicamente com base nas seguintes diretivas: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = sob demanda - os processos são criados sob demanda (em oposição à criação dinâmica, quando pm.start_servers são iniciados quando o serviço é iniciado).
pm = estático — o número de processos filhos é fixo e indicado pelo parâmetro pm.max_children.
Para obter detalhes, consulte .
Semelhanças entre o gerenciador de processos PHP-FPM e o controlador de frequência da CPU
Isso pode parecer fora de tópico, mas vou vincular isso ao tópico de configuração do PHP-FPM. Quem nunca experimentou lentidão do processador pelo menos uma vez - em um laptop, máquina virtual ou servidor dedicado. Lembra da escala de frequência da CPU? Estas opções estão disponíveis para nix e Windows podem melhorar o desempenho e a capacidade de resposta do sistema alterando a configuração de aceleração do processador de ondemand em desempenho*. Desta vez, vamos comparar as descrições e observar as semelhanças:
governador = sob demanda — escalonamento dinâmico da frequência do processador dependendo da carga atual. Salta rapidamente para a frequência máxima e depois a reduz à medida que os períodos de inatividade aumentam.
governador=conservador= escala de frequência dinâmica dependendo da carga atual. Aumenta e diminui a frequência de forma mais suave do que sob demanda.
Governador = desempenho — a frequência é sempre máxima.
Para obter detalhes, consulte .
Veja as semelhanças? Queria mostrar essa comparação para te convencer de que é melhor usar pm estático para PHP-FPM.
Para o parâmetro regulador do processador atuação ajuda a aumentar o desempenho com segurança porque depende quase inteiramente do limite de CPU do servidor. Além disso, é claro, também existem fatores como temperatura, carga da bateria (em um laptop) e outros efeitos colaterais do funcionamento constante do processador a 100%. A configuração de desempenho garante o desempenho mais rápido do processador. Leia, por exemplo, sobre , com o qual o painel RPi utilizará o regulador atuação, onde a melhoria de desempenho será mais perceptível devido à baixa velocidade do clock da CPU.
Usando pm static para obter desempenho máximo do servidor
Opção PHP-FPM pm estático depende em grande parte da memória livre no servidor. Se a memória estiver baixa, é melhor escolher ondemand ou dinâmico. Por outro lado, se você tiver memória, poderá evitar a sobrecarga do gerenciador de processos PHP configurando pm estático até a capacidade máxima do servidor. Em outras palavras, se tudo for bem calculado, é preciso estabelecer pm.estático ao volume máximo de processos PHP-FPM que podem ser executados, sem criar problemas com pouca memória ou cache. Mas não tão alto a ponto de sobrecarregar os processadores e acumular um monte de operações PHP-FPM esperando para serem executadas.
Na captura de tela acima, o servidor tem pm = estático e pm.max_children = 100, e isso ocupa aproximadamente 10 GB dos 32 disponíveis. Preste atenção nas colunas destacadas, tudo está claro aqui. Nesta captura de tela havia aproximadamente 200 usuários ativos (mais de 60 segundos) no Google Analytics. Neste nível, aproximadamente 70% dos processos filhos do PHP-FPM ainda estão ociosos. Isso significa que o PHP-FPM está sempre configurado para a quantidade máxima de recursos do servidor, independentemente do tráfego atual. Um processo ocioso aguarda picos de tráfego e responde instantaneamente. Você não precisa esperar até pm criará processos filhos e os encerrará quando o período expirar pm.process_idle_timeout. Eu configurei o valor para muito alto pm.max_requestsporque este é um servidor funcional sem vazamentos de memória em PHP. Você pode instalar pm.max_requests=0 com static se você estiver totalmente confiante nos scripts PHP existentes e futuros. Mas é melhor executar novamente os scripts ao longo do tempo. Defina um grande número de solicitações, pois queremos evitar custos desnecessários de PM. Por exemplo, pelo menos pm.max_requests=1000 - dependendo da quantidade pm.max_children e o número de solicitações por segundo.
A captura de tela mostra o comando , filtrado por u (usuário) e nome de usuário do PHP-FPM. Apenas os primeiros 50 processos são mostrados (não contei exatamente), mas essencialmente top mostra as principais estatísticas que cabem na janela do terminal. Neste caso classificado por% CPU (%CPU). Para ver todos os 100 processos PHP-FPM, execute o comando:
top -bn1 | grep php-fpmQuando usar pm ondemand e dinâmico
Se você usar pm dinâmico, ocorrem erros como este:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total childrenTente alterar o parâmetro, o erro não irá desaparecer, como . Neste caso, o valor pm.min era muito pequeno e, como o tráfego da web varia muito e tem picos altos e vales profundos, é difícil ajustar adequadamente o pm. dinâmico. Normalmente pm é usado ondemand, . Mas isto é ainda pior, porque ondemand encerra processos ociosos a zero quando há pouco ou nenhum tráfego, e você ainda terá a sobrecarga da mudança de tráfego. A menos, é claro, que você estabeleça um tempo de espera enorme. E então é melhor usar pm.estático + número alto pm.max_requests.
PM dinâmico e especialmente ondemand pode ser útil se você tiver vários pools PHP-FPM. Por exemplo, você hospeda várias contas cPanel ou vários sites em pools diferentes. Eu tenho um servidor com, digamos, mais de 100 contas cpanel e cerca de 200 domínios, e pm.static ou mesmo dinâmico não me salvariam. Tudo que você precisa aqui é ondemandafinal, mais de dois terços dos sites recebem pouco ou nenhum tráfego, e com ondemand todos os processos filhos cairão, o que nos poupará muita memória! Felizmente, os desenvolvedores do cPanel perceberam isso e definiram o valor como padrão ondemand. Anteriormente, quando o padrão era dinâmico, o PHP-FPM não era adequado para servidores compartilhados ocupados. Muitos usaram suPHP, porque tarde dinâmico memória consumida mesmo com pools ociosos e contas cPanel PHP-FPM. Muito provavelmente, se o tráfego for bom, você não ficará hospedado em um servidor com um grande número de pools PHP-FPM (hospedagem compartilhada).
Conclusão
Se você estiver usando PHP-FPM e seu tráfego for intenso, os gerentes de processo ondemand и dinâmico para PHP-FPM terão rendimento limitado devido à sua sobrecarga inerente. Entenda seu sistema e configure processos PHP-FPM de acordo com a capacidade máxima do servidor. Primeiro set pm.max_children dependendo do uso máximo de PM dinâmico ou ondemande, em seguida, aumente esse valor para um nível em que a memória e o processador funcionem sem serem sobrecarregados. Você notará que com pm estático, como você tem tudo na memória, os picos de tráfego causarão menos picos de CPU ao longo do tempo, e as médias de carga do servidor e da CPU se estabilizarão. O tamanho médio do processo PHP-FPM depende do servidor web e requer configuração manual, portanto, gerenciadores de processos mais automatizados são dinâmico и ondemand - mais popular. Espero que o artigo tenha sido útil.
UPD Gráfico de benchmark adicionado . Se os processos PHP-FPM estiverem na memória, o desempenho aumenta às custas do consumo de memória onde eles ficam e esperam. Encontre a melhor opção para você.
Fonte: habr.com