Planeamento da capacidade do PHP-FPM: calcular o número de workers, a memória RAM e o número de pedidos simultâneos

O que limita um worker do PHP-FPM

O PHP-FPM gere os processos PHP em grupos. Um Trabalhador processa uma solicitação de cada vez; a configuração do pool pm.max_children limita o número de workers disponíveis em simultâneo e, consequentemente, o número de pedidos PHP processados em simultâneo por este pool. No caso de existirem vários pools, o limite aplica-se apenas ao pool em questão, não se aplicando automaticamente a todo o servidor.

Este número não corresponde ao número de visitantes registados, nem é um valor direto das solicitações por segundo. Um visitante pode gerar várias solicitações, enquanto um utilizador registado não ocupa um worker entre duas ações. Por outro lado, uma única solicitação lenta pode ocupar um worker por mais tempo do que várias solicitações curtas consecutivas.

Além disso, nem todas as visitas a páginas chegam ao PHP-FPM. Se o servidor Web fornecer diretamente um ficheiro estático ou se um cache a montante responder integralmente a um pedido, não é necessário um worker PHP, dependendo da arquitetura. Por outro lado, falhas de cache, utilizadores autenticados e páginas de administração podem continuar a gerar pedidos PHP e aumentar temporariamente a carga do sistema.

Para o planeamento da capacidade, há, portanto, duas questões distintas que são decisivas: quantos workers cabem, incluindo uma reserva, na RAM disponível? E quantos workers são necessários para o tráfego que chega efetivamente ao pool, de modo a que os pedidos não tenham de esperar por um tempo excessivamente longo? Um valor elevado para pm.max_children não responde, por si só, a nenhuma destas perguntas.

Mesmo que haja memória suficiente, a CPU, a base de dados ou os serviços externos podem limitar a capacidade prática. Nesse caso, os workers adicionais permitem, sim, mais tarefas PHP em paralelo, mas podem, ao mesmo tempo, aumentar a pressão sobre um serviço que já está lento. O valor do pool é, portanto, um limite operacional e não uma garantia de desempenho.

Compreender o gestor de processos e a fila

O Gestor de processos define quando o PHP-FPM disponibiliza os workers. Em static o número de processos em espera corresponde ao valor de pm.max_children. Isto permite planear bem o número de processos, mas também ocupa recursos, mesmo com uma carga de trabalho reduzida. O limite máximo, por si só, tem de continuar a corresponder à memória disponível.

Em dynamic o FPM ajusta o número de processos: o número inicial, bem como o número mínimo e máximo de trabalhadores livres, são também definidos. No caso de ondemand Os workers só são criados quando necessário e são encerrados após um período de inatividade configurado. Isto pode poupar recursos em pools raramente utilizados; no entanto, em caso de um pico de carga repentino, é necessário criar primeiro nova capacidade de processamento.

Se todos os trabalhadores estiverem ocupados, os pedidos adicionais podem ser colocados na Fila de ouvintes aguardar um processo disponível. O estado do FPM indica, entre outros aspetos, o tamanho atual e o tamanho máximo da fila. No entanto, um único valor máximo elevado não indica se o conjunto está sobrecarregado nesse momento; para isso, é necessário um contexto temporal.

Uma fila maior não cria trabalhadores adicionais nem acelera uma base de dados lenta. Pode aceitar pedidos temporariamente, mas limita-se a antecipar o tempo de espera para antes do processamento em PHP. Por isso, para decidir sobre o gestor de processos, são importantes tanto a evolução típica da carga como as consequências de picos de tráfego de curta duração.

Classificar corretamente a memória do Worker

Não é possível determinar de forma fiável a necessidade de memória de um worker apenas com base num limite de configuração do PHP. Para efeitos de planeamento, os dados de processo em condições de carga adequadas são mais úteis. Nesse contexto, faz diferença se estiveres a analisar a memória residente de um único processo ou se pretenderes avaliar o consumo de todo um grupo de workers do PHP-FPM.

RSS descreve a memória residente de um processo. Se vários trabalhadores utilizarem as mesmas páginas de memória, estas podem estar incluídas nas respetivas RSS. Se somares os valores de RSS de todos os trabalhadores, as páginas partilhadas podem, em determinadas circunstâncias, aparecer várias vezes; por isso, a soma não constitui uma indicação precisa da memória física partilhada.

PSS distribui as páginas partilhadas proporcionalmente pelos processos envolvidos. A soma dos valores PSS de um grupo de processos é, por isso, frequentemente mais útil para o planeamento da memória desse grupo do que a soma dos valores RSS. No entanto, trata-se apenas de um instantâneo: se o número de processos que partilham as páginas se alterar, as respetivas proporções também se alteram.

Analise vários workers em pedidos típicos e também em pedidos que exigem muito da memória. Um processo recém-iniciado ou uma média isolada pode subestimar as necessidades futuras. O PSS total do pool para diferentes números de trabalhadores e estados de carga ajuda a obter um valor aproximado conservador; uma extrapolação para um número maior de trabalhadores permanece incerta devido às proporções variáveis entre os recursos comuns e privados.

O PHP-memory_limit não é um valor fiável para a memória total do sistema operativo de um processo FPM e não substitui essa observação. A memória partilhada, por exemplo, pela OPcache, não deve ser deduzida uma segunda vez do orçamento de forma generalizada, caso já esteja incluída proporcionalmente no PSS do pool utilizado. No entanto, é necessário ter em conta outros serviços e uma reserva.

Calcular o orçamento de RAM e o número de trabalhadores

O ponto de partida é a memória RAM efetivamente disponível: num host, a memória utilizável para os serviços; num contentor, o limite efetivo de memória. Subtraia disso as necessidades do sistema operativo, do servidor Web, de uma eventual base de dados local e de outros serviços. Outros conjuntos de FPM e uma reserva para o consumo variável também devem ser tidos em conta no cálculo.

A parte restante é a Orçamento comum. Para obter o valor estimado do worker, observa a soma PSS dos workers do pool com diferentes números de processos e condições de carga. Tem em conta tanto as solicitações típicas como os pontos finais que exigem muita memória. Divida a respetiva soma pelo número de trabalhadores em análise e deduza um valor aproximado prudente a partir de várias observações.

O cálculo que se segue é um exemplo ilustrativo, não uma medição. Os valores assumidos servem apenas para demonstrar o raciocínio matemático; não constituem uma recomendação para uma aplicação específica. O resultado é arredondado para um número inteiro de trabalhadores.

Os 25 workers não garantem uma alocação segura. O PSS distribui as páginas partilhadas proporcionalmente e varia consoante o número de processos que partilham essas páginas. Uma composição diferente de pedidos também pode alterar as necessidades de memória privada; por isso, a estimativa deve ser verificada em relação ao consumo total observado e ao limite existente.

Se a memória partilhada, como o OPcache, já estiver incluída proporcionalmente no total de PSS utilizado, não a deduzas novamente de forma global como um item adicional completo. No entanto, prevê uma reserva para as partes de memória que não estejam abrangidas pela tua análise. Especialmente no caso de um limite de contentores, o que conta, em última análise, é o consumo de todos os processos dentro desse limite, e não apenas a soma estimada dos workers.

Um worker recém-iniciado, por si só, não é muito significativo como base: é possível que ainda não tenha processado nenhuma solicitação complexa. Por isso, compare vários momentos e registe quais os pontos finais e quantos «workers» estiveram envolvidos em cada um deles. Desta forma, é possível verificar se o valor aproximado escolhido se mantém válido mesmo em condições de funcionamento menos favoráveis, mas realistas.

Estimar o número de trabalhadores necessários com base nos pedidos

O cálculo da RAM descreve quantos workers se prevê que possam ser acomodados. Por outro lado, para determinar a necessidade, o que conta é o número de pedidos PHP que chegam efetivamente ao pool em questão e o tempo que cada um deles ocupa um trabalhador. Como primeira aproximação, aplica-se o seguinte: o número médio de trabalhadores ocupados simultaneamente é igual ao número de pedidos PHP por segundo multiplicado pelo tempo médio de ocupação de um trabalhador, em segundos.

Exemplo de cálculo ilustrativo, não se trata de uma medição: partindo do pressuposto de 20 pedidos PHP por segundo e de um tempo médio de processamento de 0,25 segundos, estão, em média, cinco workers ocupados. Trata-se de uma média relativa ao período em análise. Isto não significa que estejam sempre exatamente cinco processos a funcionar, nem que cinco sejam suficientes como limite do pool para picos de tráfego de curta duração.

Para calcular o número de pedidos, não se devem considerar todas as visualizações de páginas sem verificação. Se uma cache fornecer muitas respostas sem recorrer ao PHP, esses acertos não sobrecarregam o pool. Por outro lado, os erros de cache, os visitantes com sessão iniciada e os acessos administrativos podem, por vezes, gerar mais trabalho para o PHP do que a média calculada ao longo do dia poderia sugerir.

O Tempo de ocupação do trabalhador inclui também os tempos de espera durante o processamento, por exemplo, enquanto se aguarda uma resposta de uma base de dados ou de um serviço externo. Não deve ser automaticamente equiparado ao tempo de resposta visível no navegador. De acordo com fastcgi_finish_request() o PHP pode já ter concluído a resposta para o cliente e, mesmo assim, continuar a executar tarefas no worker.

Para garantir tempos de espera aceitáveis, é necessário uma margem acima da ocupação média. A dimensão dessa margem depende, entre outros fatores, das flutuações de carga, dos pontos finais lentos e da meta de tempo de resposta pretendida. Multiplicar o número de pedidos de pico por segundo por um percentil de latência elevado pode constituir uma análise cautelosa do cenário, mas não é uma previsão precisa das filas de espera.

Por isso, considere vários períodos separadamente: um pico de atividade de curta duração e um tráfego noturno mais calmo podem resultar na mesma média diária que um funcionamento mais uniforme, mas apresentam requisitos diferentes. Se o tempo de ocupação aumentar devido a um backend lento, o número médio de trabalhadores ocupados também aumenta, mesmo com a mesma taxa de chegadas. A procura não é, portanto, apenas uma característica do fluxo de visitantes.

Derivar as configurações do pool do planeamento

Compara agora o limite máximo baseado na RAM com a necessidade estimada, incluindo uma margem de segurança. Se a necessidade for inferior a esse valor, escolhe um valor inicial conservador para pm.max_children, que não tem de esgotar o orçamento. No exemplo ilustrativo, 25 seria o limite teórico de RAM, mas não necessariamente a configuração adequada; a CPU e o backend podem já impor limites antes disso.

Se a necessidade estimada for superior ao limite da RAM, aumentar esse limite não resolve o problema: pode colocar o anfitrião ou o contentor sob pressão de memória. Por outro lado, um limite muito baixo pode fazer com que as solicitações fiquem em espera. Neste caso, melhore, por exemplo, o tempo de execução ou a utilização da cache e verifique se são necessários recursos adicionais ou uma limitação da carga de entrada.

Em dinâmico Além do limite máximo, define o número inicial, bem como o número mínimo e máximo de trabalhadores disponíveis. Os valores iniciais e de reserva devem corresponder à carga prevista e permanecer dentro do limite máximo. Uma capacidade reservada insuficiente pode implicar uma necessidade adicional de inicialização em caso de carga repentina; por outro lado, um número elevado de processos livres de forma permanente consome recursos.

Em a pedido Os workers só são criados quando necessário; o tempo de inatividade até ao seu encerramento é definido separadamente. Isto pode ser útil para pools raramente utilizados, mas requer especial atenção em caso de aumentos rápidos da carga. Também neste caso, limita-se pm.max_children o número de trabalhadores do conjunto disponíveis em simultâneo.

Vários sites alojados no mesmo servidor não recebem, de forma independente, toda a RAM livre disponível. Defina os limites máximos de cada pool em conjunto com os restantes serviços e a reserva. Um limite global de processos FPM, caso tenha sido configurado, pode ser aplicado adicionalmente, mas não substitui nem os orçamentos individuais dos pools nem a verificação da capacidade da CPU e da base de dados.

Após as alterações, verifica a carga real e os tempos de espera ao longo de períodos adequados, em vez de considerar o valor inicial como definitivo. No caso do alojamento gerido, os dados de processo ou as definições do pool podem não estar diretamente acessíveis; nesse caso, utilize as métricas e as opções disponibilizadas pelo fornecedor. As definições disponíveis dependem também da versão do PHP e do ambiente operativo.

Monitorizar o estado do FPM e a memória

A página de estado do FPM mostra se os workers planeados são suficientes sob carga real. Protege o ponto final de estado protegido do acesso público: pode revelar informações confidenciais sobre pedidos e recursos. Um «status listener» configurado separadamente pode permanecer acessível mesmo quando o pool principal estiver sobrecarregado; verifica a sua disponibilidade e configuração para a tua versão do PHP e para a configuração do servidor web.

Considera os valores como séries temporais juntamente com o volume de pedidos e os tempos de resposta. Um valor máximo antigo da fila não comprova uma sobrecarga atual; da mesma forma, no caso dos contadores, o seu aumento desde a última observação é mais significativo do que o mero valor total. Tém em conta, neste contexto, o arranque do pool ou os reinícios, que alteram o período de referência.

No caso de um FPM-Worker conhecido, é possível obter valores de memória agregados em modo de leitura num sistema Linux com a interface proc disponível. Substitua PID através do ID real do processo; é necessário dispor dos direitos de acesso adequados. Repete a observação para vários trabalhadores e estados de carga, em vez de deduzir um tamanho de pool permanente a partir de um único processo.

cat /proc/PID/smaps_rollup

Analisar pedidos lentos e filas

Uma loja pode apresentar muitos workers ativos, embora a execução do PHP em si não seja o principal gargalo. Se houver pedidos em espera devido a consultas lentas à base de dados, os trabalhadores ficam bloqueados durante esse período. Se chegarem mais pedidos, a fila do listener pode aumentar e o tempo de resposta pode prolongar-se, mesmo que a CPU ainda disponha de reservas.

Um limite mais elevado de workers pode, nesta situação, permitir que mais pedidos cheguem simultaneamente à base de dados. Isso pode Impressão no backend aumentar e prolongar ainda mais os tempos de espera. Por isso, compara a evolução ao longo do tempo da utilização do FPM e da fila de espera com a carga da base de dados, as consultas lentas e as chamadas a serviços externos, antes de aumentares o limite.

O Slowlog do FPM ajuda a identificar chamadas PHP demoradas: para pedidos que excedam um limiar configurado, o FPM pode registar um backtrace. Este mostra um ponto de execução e não constitui um perfil completo de todo o pedido. Os pontos recorrentes podem ser comparados com a duração da solicitação e as métricas do backend; o Guia para a análise do slowlog do PHP-FPM explica a análise posterior.

O tempo limite também deve ser distinguido da capacidade real. No nginx, designa-se fastcgi_read_timeout o intervalo permitido entre operações de leitura sucessivas do servidor FastCGI, e não, de forma generalizada, a duração total do pedido. Um valor mais elevado pode permitir tempos de espera mais longos, mas não cria trabalhadores adicionais nem acelera a base de dados.

Limites de capacidade e próximos passos

Se o orçamento de RAM não for suficiente para as necessidades estimadas, um valor mais elevado para pm.max_children Não ignore este conflito de objetivos: os processos adicionais também requerem memória. Em vez disso, verifica se é possível reduzir o número de pedidos PHP ou a duração da ocupação dos workers. A medida mais adequada depende da origem da carga observada.

Uma cache melhor aproveitada pode interceptar chamadas repetidas, enquanto uma execução mais rápida do PHP e os acessos à base de dados libertam os workers mais cedo. O trabalho em segundo plano adequado pode ser deslocado para fora do percurso imediato da solicitação; no entanto, esse trabalho também requer recursos próprios. Um limite de carga protege o backend durante os picos de tráfego, mas pode fazer com que as solicitações fiquem em espera ou sejam rejeitadas.

Mais memória RAM pode permitir um maior número de workers, caso a memória seja, de facto, o limite determinante. Se a CPU, a base de dados ou um serviço externo já estiverem a funcionar no limite da sua capacidade, esta deve também ser tida em conta. Por isso, mais memória, por si só, não garante nem tempos de resposta mais curtos nem um maior débito.

Se a necessidade de memória de cada trabalhador aumentar ao longo do seu ciclo de vida, pode pm.max_requests provocar a sua substituição regular. Isto pode ajudar a lidar com fugas de memória em bibliotecas de terceiros, mas não resolve a causa do problema. Após uma alteração, continue a monitorizar a memória do pool e o comportamento das solicitações, em vez de tratar o mecanismo de reinício como um substituto da deteção de erros.

Para uma decisão de arquitetura mais abrangente, o Comparação entre o NGINX Unit e o PHP-FPM Contexto: O NGINX Unit foi arquivado e já não recebe atualizações. Independentemente da arquitetura escolhida, deves efetuar as alterações com base em séries temporais Verificar: em casos de volume de pedidos semelhante, compare a fila de espera, a carga de trabalho dos workers, a memória e os tempos de resposta. Desta forma, é possível determinar se um ajuste resolveu efetivamente o estrangulamento ou se apenas o deslocou.