Apache 2.4 - Módulos de Multiprocessamento - MPM

Com a versão 2.4 no Debian Jessie, a MPM event entrou em estado de produção. Neste artigo, vamos diferenciar "prefork", "worker" e "event" para entender um pouco mais seu funcionamento. As informações são baseadas no manual do Apache 2.4.

[ Hits: 34.843 ]

Por: Perfil removido em 04/08/2014


MPM worker



Essa MPM implementa um servidor multiprocesso e multithread. Utilizando threads é possível atender mais solicitações HTTP com menos processos e, deste modo, consumir menos recursos de hardware. No modo worker, os processos-filhos têm capacidade de lançar vários threads que ouvem por requisições.

Isso mantém a estabilidade do sistema isolando as requisições em cada processo filho e seus vários threads. Caso uma aplicação errante derrube um processo-filho, o servidor ainda é capaz de continuar atendendo requisições através de outros processos-filhos e seus threads.

A mais importante diretiva utilizada pelo método Worker é ThreadsPerChild, que controla o número de threads lançados por processo. Vejamos como esse módulo funciona na prática.

Um processo pai (daemon) é responsável por lançar processos filhos. Cada um desses processos filhos cria um certo número de servidores HTTP que se apresentam na forma de threads. São os threads que ouvem pelas conexões e quando elas chegam, eles passam o controle para o seu processo pai.

Apache irá manter um conjunto de threads spare ou threads idle, evitando que a requisição HTTP tenha que esperar pela criação do thread que irá atendê-la. O número de processos inicialmente lançados, é definido na diretiva StartServers. Observe que em relação ao módulo prefork esse valor é sempre menor, pois cada processo lançará vários threads compensando o número menor de processos em várias vezes.

O servidor HTTPD avalia o número de threads ociosos de todos os processos e baseado nos valores de MinSpareThreads e MaxSpareThreads, o servidor decidirá por lançar ou matar processos. Apache gerencia esses valores automaticamente e de modo satisfatório para sites que não são movimentados.

Para sites que atendem muitas requisições, o ajuste manual é necessário. A diretiva MaxRequestWorkers define o número máximo de threads permitidos em todos os processos filhos. O número máximo de processos filhos é definido pela divisão do valor de MaxRequestWorkers por ThreadsPerChild.

Duas diretivas definem o limite hard do número de processos filhos e servidores de threads em um processo filho. Essas diretivas somente podem ser modificadas com a parada total do serviço. A diretiva ServerLimit define um limite hard para o número de processos filhos e deve ser maior ou igual ao valor definido para MaxRequestWorkers dividido por ThreadsPerChild.

A diretiva ThreadLimit é um limite hard para o número de servidores de threads e deve ser maior ou igual à diretiva ThreadsPerChild.

Independente do conjunto de processos filhos, pode haver alguns processos que são terminados e um de seus threads ainda está ativo lidando com uma conexão. O valor da diretiva MaxRequestWorkers (define o número máximo de conexões simultâneas), pode interferir bloqueando novos processos, pois entende que o thread está ativo.

Para evitar esse comportamento, desabilite o término de processos-filhos definindo o valor de MaxConnectionPerChild para zero e deixe os valores de MaxSpareThreads e MaxRequestWorkers, iguais. A configuração padrão para o módulo worker é:

 ServerLimit         16
 StartServers        2
 MaxRequestWorkers   400
 MinSpareThreads     75
 MaxSpareThreads     250
 ThreadsPerChild     25


A menos que suexec esteja sendo utilizado, essas diretivas vão configurar os privilégios com que scripts CGI são executados.

A diretiva MaxConnectionsPerChild controla a frequência com que os processos são reciclados, matando processos velhos e lançando novos. Isso é uma função de segurança do sistema.

A MPM worker utiliza um Mutex (mpm-accept) para criar uma lista com as requisições que chegam. Consulte a documentação para saber como ajustar o valor do mutex.

Diretivas para worker:

ServerLimit - é uma diretiva comum em prefork, worker ou event utilizada para definir o limite superior do número de processos. Em worker essa diretiva, em combinação com ThreadLimit configura o valor máximo de MaxRequestWorkers definindo o tempo de vida útil de um processo HTTPD. Essa diretiva não pode ser reconfigurada em tempo de execução. Se o valor dessa diretiva e MaxRequestWorkers forem definidos de forma muito alta haverá um grande consumo de memória compartilhada de modo que o sistema pode não conseguir manipular, se tornando instável, ou até impedindo o serviço HTTPD de ser inicializado. O valor padrão para essa diretiva é 16.

StartServers - é uma diretiva comum em prefork, worker ou event utilizada para definir o número de processos filhos criados no momento da inicialização. O padrão para worker é 3.

MaxRequestWorkers - é uma diretiva comum em prefork, worker ou event utilizada para definir o número máximo de conexões que são processadas simultaneamente. Qualquer requisição que chegar, após esse valor ser atingido, será colocada em uma fila de espera. Isso ocorrerá até atingir o valor definido em ListenBackLog, que define o tamanho da fila. Acima desse valor as requisições são descartadas. As requisições da fila são atendidas tão logo um thread seja liberado por sua ordem de chegada. Para prefork esse valor é 256. Para worker e event é definido pelo valor de ServerLimit multiplicado por ThreadsPerChild. Esses valores devem ser mutuamente atualizados para evitar erros.

MinSpareThreads - define o número mínimo de threads ociosos para lidar com requisições entrantes. Comum em worker e event. Esse valor é medido para todo o servidor. Se o número de threads for inferior ao valor definido, então, o servidor pode gerar processos filhos para atender esse valor.

MaxSpareThreads - essa diretiva é comum para worker e event. É utilizada para definir o valor do número máximo de threads ociosos. Se houver mais threads ociosos que o valor dessa diretiva, então, processos filhos serão mortos até ser menor que esse valor. Apache irá corrigir o valor informado aqui de acordo com a seguinte regra. O valor deve ser maior ou igual a soma de MinSpareThreads e ThreadsPerChild.

ThreadsPerChild - essa é uma diretiva comum a worker e event, utilizada para definir o número de threads criados por cada processo filho. O processo filho cria esses threads no momento de sua criação e não cria mais threads depois. O valor padrão é 25. O total de threads deve ser suficiente para comportar a carga de requisições recebida pelo servidor.

Página anterior     Próxima página

Páginas do artigo
   1. Conceitos básicos
   2. MPM prefork
   3. MPM worker
   4. MPM event
Outros artigos deste autor

Usando tabelas no editor de textos do OpenOffice

PLC no Linux alguém já pensou nisso?

Como instalar as extensões Dash To Dock e Hide Top Bar no Gnome 45/46

Banda Larga é um direito de todos!

Ocomon - Instalação e configuração

Leitura recomendada

Configurando Linux para Desenvolvimento de Sites

Instalação e configuração do gdesklets no Slackware 10

Como transformar seu DVD/RW em um disco de backup como se fosse um HD convencional

Configurando servidor MikroTik com Hotspot e páginas de aviso (atraso e bloqueio)

Pós-instalação do Arch Linux

  
Comentários

Nenhum comentário foi encontrado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts