Apache - desvantagem de um grande número de processos httpd sempre em execução

Question

Existe algum problema em ter um grande número de processos de sobressalentes httpd sempre em execução? Fiz um teste em que aumentei StartServers e MinSpareServers em 1.000 e medi o aumento no uso de memória e foi de apenas 500MB.

Em vista disso, eu estava pensando que, como temos muita RAM, para obter um ótimo desempenho durante períodos de tráfego em rajadas, podemos ter StartServers e MinSpareServers definido para cerca de 1.000 e, é claro, definido ServerLimit e MaxRequestWorkers (anteriormente MaxClients ) para algo maior.

Há alguma desvantagem de fazer isso que eu não estou ciente de assumir que nosso servidor é capaz de lidar com muitas solicitações de uma só vez e usamos MaxConnectionsPerChild como precaução contra vazamentos de memória?

Como uma observação para quem pensa que 0,5MB por processo de httpd está incorreto, pelo que li o motivo pelo qual o uso de memória do Apache é muito menor do que o relatado para um processo individual por top é que ele usa bibliotecas compartilhadas .

    

Answer 1

Estou preocupado com sua metodologia de testes. Parece que você está gerando um monte de processos, em seguida, olhando para o uso de memória. O problema é que, quando são gerados pela primeira vez, estão compartilhando uma quantidade máxima de memória e não possuem dados locais por processo armazenados.

Quando você começar a usá-los, verá que esses processos começam a precisar de mais memória. Isso é verdade mesmo na ausência de vazamentos de memória, mas se você estiver usando extensões que estão vazando, o problema fica muito ruim, muito rápido.

Eu recomendaria fazer um teste de carga realista, sob uma variedade de condições, antes de deixar uma configuração como essa para ser executada sem supervisão rigorosa.

    

Answer 2

O que você está tentando evitar são solicitações de entrada que fazem com que novos processos sejam bifurcados a uma taxa maior do que os processos mais antigos podem atender às conexões mais antigas. Esse risco está causando uma situação em que o sistema continua criando novos processos que consomem a memória disponível e começa a aumentar a frequência em que o sistema operacional usa swap. O que, por sua vez, causa um grande aumento na E / S do disco, onde o sistema está apenas trocando páginas da memória física para a memória virtual (no disco) e vice-versa, sem qualquer benefício real para a carga de trabalho.

A fórmula geral para começar é:

(Memória total - Memória do sistema operacional - memória do banco de dados) / Tamanho por processo do Apache.

A fórmula é apenas parte da equação. Quanto mais você dá o sistema e a memória do MySQL, mais cache do sistema de arquivos eles fazem para você e evita que o disco seja muito caro. Se o banco de dados não estiver no mesmo sistema, isso é um problema menor.

O outro cenário que acontece se você não ajustar o Apache corretamente e a frequência de aumentos de troca é que os usuários iniciam o hit stop e recarregam, aumentando artificialmente a carga no servidor. Você pode controlar a configuração MaxRequestWorkers para que seu servidor não gere tantos filhos que ele comece a trocar. Parece simples que você apenas determine o tamanho do seu processo Apache médio, olhando para sua lista de processos através de uma ferramenta como top ou smem e então divida isso em sua memória total disponível, enquanto deixa memória suficiente para outros processos que você irá usar. obter uma imagem mais precisa.

O outro parâmetro-chave neste cenário é ServerLimit . Se ServerLimit for definido com um valor muito maior do que o necessário, a memória compartilhada extra não utilizada será alocada. Se ServerLimit e MaxRequestWorkers estiverem definidos como altos. O desempenho do httpd de Apache e a estabilidade geral geral do httpd do Apache podem começar a se tornar um problema.

    

Answer 3

Não há problema em ter um grande número de processos de sobressalentes httpd sempre em execução. Na verdade, é uma boa ideia.

O ponto principal é: se você quiser que o httpd atinja esse número de processos, é melhor chegar a você desde o início e ter certeza de que funciona. Em outras palavras, não dimensione automaticamente, simplesmente pré-dimensione. Menos surpresa.

O segundo ponto é: se você não precisa compartilhar recursos (principalmente a RAM neste caso) ou se adaptar a serviços diferentes em execução em momentos diferentes em seu servidor, não faz sentido alterar o número de processos ao longo do tempo. Aloque um orçamento de RAM para o seu httpd e crie as instâncias necessárias para lidar com muitas solicitações simultâneas.

15 anos atrás, as pessoas compartilhavam muitas coisas em um único servidor e fazia sentido adaptar o número de httpds à carga de trabalho. Atualmente, a maioria das pessoas usa um servidor por aplicativo: a maior parte do tempo não usa todos os seus recursos, mas o desempenho é mais previsível e a análise e o ajuste de desempenho são muito mais fáceis.

Embora haja uma pegadinha em uma situação específica que é realmente tão comum: Apache + mod_php (ou qualquer interpretador embutido em qualquer httpd). Aqui o mod_php muda completamente o negócio porque ele se torna uma questão de escalonamento de aplicativos e não escalonamento de httpd, que é outro assunto (de extensão) e requer uma abordagem diferente (um trabalhador pré-moldado de 1000 não funciona).