Por que o gerenciamento de processo estático versus dinâmico afeta tanto o uso de memória para o php-fpm?

Question

Eu recentemente migrei um cliente para uma instância do EC2 executando Nginx + PHP-FPM. Quando configurei o servidor pela primeira vez, defini pm=static com 40 processos de trabalho. Depois de uma semana, resolvi experimentar com pm=dynamic com um máximo de 200 e um mínimo de 30 trabalhadores.

O que eu notei foi que, com uma configuração estática, 40 processos ocuparam cerca de 2,3 GB de memória, enquanto que, com a dinâmica, vi picos de 60 processos usando apenas 1,2 GB de memória.

Veja o quadro abaixo da New Relic, minhas anotações em vermelho.

Você pode ver que durante o dia de 25/11 eu mudei de estático para dinâmico e reiniciei o php-fpm. Depois disso, podemos ver que 48 processos tomam apenas 990MB e 60 processos ocupam apenas 1.2GB de memória.

O que pode contribuir para essa disparidade entre o gerenciamento estático e dinâmico? Será que, com a dinâmica, eu defini as solicitações máximas para 50? Talvez com o uso de memória estática foi devido mais aos vazamentos de memória, em vez de algo interno com php-fpm?

    

Answer 1

pm.max_requests não é específico para nenhum modo do Gerenciador de processos ( pm ). Seus benefícios são reaparecer processos de trabalho após a quantidade especificada de solicitações que eles tratam individualmente.

Poderia evitar vazamentos de memória em casos extremos, mas normalmente apenas libera alocações de memória acumuladas quando scripts com muita memória eram executados. As alocações de memória se acumulam e a quantidade total de memória alocada aumenta, mas é liberada apenas na saída (assim quando o respawn).

Como você diz, parece que você não ativou pm.max_requests ao usar pm static . Você deveria ter visto uma diferença e, certamente, mais do que uma linha reta.

pm dynamic tem o benefício adicional de parar os trabalhadores, dependendo do número de processos ociosos entre eles ( pm.min_spare_servers , pm.max_spare_servers ), que são uma espécie de medição instantânea de carga. A interrupção de processos inúteis libera a memória alocada associada ao custo da manipulação do processo (CPU), que pm.min_spare_servers neutraliza garantindo um colchão de segurança em caso de picos, mantendo os funcionários ociosos prontos para processar solicitações.

Agora, se você realmente está cuidando da sua memória, pm ondemand é mais agressivo, (des) gerando processos como (não) necessários (mais). Esse modo é o mais próximo da borda, já que não absorverá picos, assim como pm dynamic , mas é o consumo mínimo de memória (com a contrapartida de usar mais CPU para fins de gerenciamento de processos).

TL; DR

As alocações de memória são empilhadas para qualquer processo de trabalho. Se uma solicitação específica estava com fome de memória, ela ocupará a alocação de memória do trabalhador de processamento, e isso não será liberado até que o processo seja interrompido.

Use pm.max_requests para reciclar processos, qualquer que seja o modo que você usa.

pm.dynamic reciclará os processos em outro critério que é load e eliminará processos quando muitos deles estiverem inativos. É mais provável que ter uma maior rotatividade de processos evite que eles fiquem com muita memória, ao custo de mais ciclos de CPU usados no gerenciamento de processos.