Trabalhadores do Apache MPM presos no crescimento G (finalizando graciosamente) - "o placar está cheio"

Question

Executando o trabalhador MPM, Apache 2.4.46, Debian 9

O acabamento gracioso dos trabalhadores só cresce com o tempo, eles parecem nunca terminar. Eventualmente, fico sem capacidade e recebo o erro "placar cheio". Se eu reiniciar o Apache, eles serão liberados.

Não acredito que tenha algo a ver com o código do meu site (php), já que muitas das solicitações suspensas são apenas GETs de imagem pura, sem php envolvido.

<IfModule mpm_worker_module>
ServerLimit 500
StartServers       10
MinSpareThreads    50
MaxSpareThreads    100
    ThreadLimit          64
    ThreadsPerChild      64
    MaxRequestWorkers     500
    MaxConnectionsPerChild   0
</IfModule>

placar

exemplo g trabalhadores

Apache durante a semana, slots grátis diminuindo

tentei ligar e desligar o keep alive

Answer 1

Quando você usa o trabalhador MPM, as solicitações são tratadas por threads que existem nos processos.

Dehttps://httpd.apache.org/docs/2.4/mod/worker.html

Um único processo de controle (o pai) é responsável por iniciar processos filhos. Cada processo filho cria um número fixo de threads de servidor conforme especificado na diretiva ThreadsPerChild, bem como um thread de ouvinte que escuta conexões e as passa para um thread de servidor para processamento quando chegam.

No Linux, um processo 'contém' threads, ou seja, um PID pode ter vários threads que compartilham memória (entre outros recursos) com outros threads nesse PID.

Na verdade, o Linux realmente só se preocupa com 'tarefas', um processo não multithread é um PID com um contêiner deumtarefa.

Ao recarregar o Apache normalmente, você está encerrando o processo que o contém. O que está acontecendo aqui é que o Apache está fazendo cada thread esperar até que todos os threads no processo que o contém sejam concluídos antes de reiniciar o PID do contêiner.

Então, no seu caso, você tem um único thread contido em todos os processos dessa lista que ainda está ocupado ou preso de alguma forma.

Você tem algumas opções.

1. Desista de esperar de qualquer maneira e reinicie.
2. Encontre o tópico do problema (pode ser um bug no aplicativo) e corrija-o.

1, é fácil. Adicione a opção de configuração GracefulShutdownTimeoutcom um valor alto, mas não estúpido. Diga 900 segundos. Por padrão, isso é infinito, o que significa que seus threads esperam para sempre até que o thread problemático termine.

A principal desvantagem disso é que você corre o risco de atingir um processo no meio de algo crítico - cujo encerramento pode, por sua vez, corromper um arquivo ou quebrar o aplicativo sutilmente. Você também corre uma chance (muito pequena) de encerrar um cliente no meio do processamento.

2, envolverá você identificar o thread que está preso na lista de trabalhadores e, em seguida, diagnosticar o que a conexão está fazendo, mas você certamente descobrirá o que poderia ser uma falha de design e poderá explicar o comportamento com mais confiança antes de simplesmente explodir afastar um tópico problemático.