configuração php5-fpm pm - (node) Nós de configurações do gerenciador de processos em termos mais leigos

Question

Eu tenho a seguinte configuração para php-fpm

[www]
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
user = www-data
group = www-data
pm = dynamic
pm.max_children = 50
pm.start_servers = 25
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 2500
pm.status_path = /php-status

Eu leio esta página de documentação .

Apreciaria uma explicação mais humana das configurações relacionadas ao pm.

Por exemplo, o que é pm = dynamic? Existem outras configurações possíveis para pm =? pm.max_children define o limite do número de solicitações simultâneas que serão atendidas.

Isso significa que, se eu tiver 51 visitantes diferentes, o php-fpm não conseguirá lidar com o 51º visitante do site?

O que acontece então? O 51º visitante obtém um 404?

Eu sou mais dev do que ops, então apreciaria uma explicação mais humana.

    

Answer 1

Existem dois tipos de gerenciamento de processador (PM). dynamic e static .

Estático

O método estático é muito simples. Você tem um número definido de filhos e o php-fpm sempre tentará manter esse número de filhos. Então, se você definir pm=static e pm.max_children = 50 , você sempre terá 50 filhos, não importa o quê.

Isso é bom se você tiver um tráfego muito consistente e bem medido. Isso evita que o desperdício de esforços cresça e encolha os trabalhadores (impacto mínimo com a dinâmica). Também reduz imprevisibilidade. Salvar CPU

Todos os outros campos não são usados se definidos como estáticos.

Dinâmico

Dinâmico permite que seus filhos fiquem com flutuações. É mais fácil entender com o nosso exemplo.

Quando o servidor inicializa, ele começa em pm.start_servers . Agora temos 25 pelo seu exemplo. Digamos que 20 deles estejam sendo usados e que outra solicitação tenha sido enviada. Depois disso, ela é veiculada, mas a contagem de seus filhos aumenta em 1, pois atingiu o limite mínimo de reposição. Lembre-se de que o processo de criação é demorado, portanto, você deve manipulá-lo com um processo que já esteja ativo. Digamos que a carga aumenta mais e agora você tem 49 filhos ativos. Então até 50 são feitos porque é o seu máximo. Agora vamos dizer que sua carga diminui e existem 14 ativos. Em seguida, ele descarregará um filho para alcançar um total de 49 crianças, conforme ele atende ao máximo de servidores reserva. Se sua carga cair ainda mais para zero, você terá 35 filhos e nunca conseguirá ir abaixo de 35 (com exceção das solicitações via max, veja abaixo). A contagem de crianças é reduzida para que você obtenha mais memória ram utilizável.

A dinâmica é um pouco "não se preocupe, vou otimizar para você dentro dos limites".

Isso é bom se você precisa manter a memória baixa. Salvar RAM

Solicitações acima do máximo

Se você tiver 50 ativos e receber outra solicitação, ela provavelmente será enfileirada pelo gerente. Embora incerto, acho que também tende a rejeitar se o tamanho da fila for ridiculamente longo. Se ele permanecer na fila por muito tempo, o solicitante, como nginx, retornará 504 para o usuário final quando o gateway tiver expirado. Para evitar algo como todas as solicitações que estão sendo expiradas devido ao congestionamento sem fim (ddos?), O nginx normalmente pára de passar a carga para um servidor inativo por um período de tempo definido em nginx (adivinhando em torno de 30 segundos) quando atingiu certo número de erros do backend.

Solicitações máximas

O valor pm.max_requests define quantos pedidos um filho deve manipular antes de se destruir para um novo processo tomar seu lugar (ou nada se ainda estiver dentro dos limites do status dinâmico atual conforme definido acima). Isso ajuda a combater vazamentos de memória (na própria criança do php-fpm ou em seu aplicativo). Portanto, se houver um vazamento de memória, o uso de memória da criança continuará aumentando. Por que ele continua subindo mesmo depois que a execução do php é concluída e é assim que o php-fpm otimiza seus processos e outras coisas ... Eu sinto que é um ensaio separado.

Para notar a prevenção de confusão indicada pelo seu post (ou falta de clareza). Isso não tem nada a ver com quantos visitantes você tem ou quantas pessoas estão visualizando seu site agora. É tudo sobre quantos php estamos processando simultaneamente. Você esperaria que a maioria dos processos fosse concluída em menos de 300 ms. Abaixo de 100ms como ideal na opinião pessoal. Com um hardware melhor, você pode processar mais rapidamente, para que você possa manipular mais visitantes (ou mais precisamente, solicitações), apesar de não haver alteração na contagem de processos simultâneos.

P.S. Tudo o que eu disse aqui aplica-se também ao apache. Apenas diferentes nomes de variáveis.