A versão não editada do artigo foi originalmente publicada em e é publicada aqui com a permissão de seu .
Vou explicar brevemente como configurar o PHP-FPM para aumentar a largura de banda, reduzir a latência e usar os recursos da CPU e da memória de forma mais estável. Por padrão, a linha PM (gerenciador de processos) no PHP-FPM é dinâmica, e se você não tiver memória suficiente, é melhor definir como sob demanda. Vamos comparar 2 opções de gerenciamento com base na documentação do php.net e ver como elas diferem da minha favorita static pm para tráfego intenso:
pm = dinâmico — o número de processos filhos é ajustado dinamicamente com base nas seguintes diretivas: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = sob demanda — processos são criados sob demanda (diferente da criação dinâmica, onde pm.start_servers são iniciados na inicialização do serviço).
pm = estático — o número de processos filhos é fixo e especificado pelo parâmetro pm.max_children.
Mais detalhes podem ser encontrados em .
Semelhanças do gerenciador de processos PHP-FPM com o regulador de frequência da CPU
Pode parecer fora de tópico, mas vou relacionar isso com a configuração do PHP-FPM. Quem já não teve seu processador lento — em um laptop, máquina virtual ou servidor dedicado? Lembra do escalonamento da frequência do processador? Essas opções, disponíveis para nix e Windows, podem aumentar o desempenho e a velocidade de resposta do sistema, se você alterar a configuração do regulador do processador de sob demanda para performance*. 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. Transições bruscas para a frequência máxima e depois a reduz quando aumentam os períodos de ociosidade.
Governador = conservador = escalonamento dinâmico da frequência com base na carga atual. Aumenta e diminui a frequência de forma mais suave do que sob demanda.
Governador = performance — a frequência está sempre no máximo.
Mais detalhes podem ser encontrados em .
Viu a semelhança? Eu queria mostrar essa comparação para convencê-lo de que o melhor a fazer é usar pm estático para o PHP-FPM.
Para o regulador de frequência, o parâmetro performance ajuda a aumentar a performance de forma segura, pois depende quase totalmente do limite do CPU do servidor. Além disso, claro, há outros fatores como a temperatura, a carga da bateria (em um laptop) e outros efeitos colaterais do funcionamento contínuo do CPU a 100%. A configuração de performance garante o funcionamento mais rápido do processador. Confira, por exemplo, sobre , com o qual o painel RPi utilizará o regulador performance, onde a melhoria de desempenho será mais notável devido à baixa frequência do CPU.
O uso de pm static para alcançar a máxima performance do servidor
O parâmetro PHP-FPM pm estático depende muito da memória livre no servidor. Se a memória for escassa, é melhor optar por sob demanda ou dinâmica. Por outro lado, se você tiver memória, pode evitar custos desnecessários do gerenciador de processo PHP, configurando pm static para a capacidade máxima do servidor. Em outras palavras, se tudo for bem calculado, deve-se configurar pm.static para o máximo de processos PHP-FPM que podem ser executados, sem causar problemas de falta de memória ou cache. Mas não tão alto ao ponto de sobrecarregar os processadores e acumular uma pilha de processos PHP-FPM esperando para serem executados..
Na captura de tela acima, o servidor tem configurado pm = static e pm.max_children = 100, e isso consome cerca de 10 GB da capacidade total de 32. Note as colunas destacadas, tudo aqui está claro. Na captura de tela, havia cerca de 200 usuários ativos (mais de 60 segundos) no Google Analytics. Neste nível, cerca de 70% dos processos filhos do PHP-FPM ainda estão inativos. Isso significa que o PHP-FPM está sempre configurado para o máximo de recursos do servidor, independentemente do tráfego atual. O processo ocioso aguarda picos de tráfego e responde instantaneamente. Você não precisa esperar que pm crie processos filhos e, em seguida, os finalize quando o período de pm.process_idle_timeoutexpirar. Eu defini um valor muito alto para pm.max_requests, pois este é um servidor em operação sem vazamentos de memória no PHP. Você pode configurar pm.max_requests = 0 com static, se tiver total confiança nos scripts PHP atuais e futuros. Mas é melhor reiniciar os scripts de tempos em tempos. Defina um número alto 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 do número de solicitações por segundo.
A captura de tela mostra o comando , filtrada por u (usuário) e nome do usuário PHP-FPM. Mostra apenas os primeiros 50 ou algo assim processos (não contei exatamente), mas, basicamente, o top exibe as estatísticas que cabem na janela do terminal. Neste caso, com ordenação por % CPU (%CPU). Para ver todos os 100 processos PHP-FPM, execute o comando:
top -bn1 | grep php-fpmQuando usar pm ondemand e dynamic
Se usar pm dinâmica, ocorrem erros semelhantes:
WARNING: [pool xxxx] parece ocupado (você pode precisar aumentar pm.start_servers ou pm.min/max_spare_servers), gerando 32 filhos, há 4 ociosos e 59 filhos no total.Tente alterar o parâmetro, o erro não desaparecerá, como . Neste caso, o valor de pm.min era muito pequeno, e como o tráfego web muda bastante e tem picos altos e quedas acentuadas, é difícil configurar pm adequadamente. dinâmica. Normalmente, pm é utilizado sob demanda, . Mas isso é ainda pior, pois sob demanda finaliza processos ociosos até zero, quando o tráfego é baixo ou inexistente, e no final você ainda terá problemas com custos ao mudar o tráfego. A menos que você tenha um tempo de espera muito grande estabelecido. E então é melhor usar pm.static + número alto pm.max_requests.
PM dinâmica e especialmente sob demanda pode ser útil se você tiver vários pools PHP-FPM. Por exemplo, você está hospedando várias contas cPanel ou vários sites em diferentes pools. Tenho um servidor onde, por exemplo, há mais de 100 contas cPanel e cerca de 200 domínios, e pm.static ou até mesmo dynamic não me atenderia. Aqui é necessário apenas sob demanda, pois mais de dois terços dos sites recebem pouco tráfego ou nenhum, e com sob demanda todos os processos filhos falharão, o que nos economizará uma quantidade significativa de memória! Felizmente, os desenvolvedores do cPanel perceberam isso e estabeleceram um valor padrão sob demanda. Antes, quando o valor padrão era dinâmica, o PHP-FPM não era adequado para servidores compartilhados carregados. Muitos usavam suPHP, porque pm dinâmica consumia memória mesmo em pools e contas cPanel ociosos do PHP-FPM. Provavelmente, com um bom tráfego você não estará hospedando em um servidor com um grande número de pools PHP-FPM (hospedagem compartilhada).
Conclusão
Se você está usando PHP-FPM e o tráfego é sério, os gerenciadores de processos sob demanda e dinâmica para PHP-FPM limitarão a largura de banda devido aos custos inerentes a eles. Analise seu sistema e configure os processos PHP-FPM de acordo com a capacidade máxima do servidor. Primeiro, defina pm.max_children dependendo do uso máximo do pm dinâmica ou sob demanda, e então aumente esse valor para o nível em que a memória e o processador funcionarão sem sobrecarga excessiva. Você notará que com pm estático, uma vez que tudo está armazenado na memória, os picos de tráfego ao longo do tempo causarão menos picos para o processador, e as médias de carga do servidor e do processador se nivelarã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âmica e sob demanda — mais populares. Espero que o artigo tenha sido útil.
ATUALIZAÇÃO Um gráfico de benchmarking foi adicionado . Se os processos PHP-FPM estão na memória, o desempenho aumenta devido ao consumo de memória, onde eles ficam aguardando. Encontre a melhor opção para você.
Fonte: habr.com
