Média de carga aceitável

Implantamos nosso novo servidor de correio Linux / Exim / Spamassassin na sexta-feira (sempre uma boa idéia para implantar no dia anterior a um longo fim de semana em que não havia administradores). A carga está pairando em torno de 1,3 na média de 15 minutos.

A máquina responde e os e-mails são entregues em tempo razoável. Podemos assumir que isso é aceitável?

Como uma certa quantidade de carga é considerada aceitável ou não? Quais métricas são usadas?

Regra básica: se o sistema for responsivo, se estiver funcionando em tempo hábil, você estará bem.

Cargas abaixo de dois não são uma grande preocupação. Os sistemas atingiram quatro ou cinco e ainda funcionam bem, embora isso seja um indicador de que há muitos problemas de enfileiramento na rede ou nas unidades (problemas de E / S podem causar altas cargas, mesmo que o sistema seja muito responsivo).

Verifique periodicamente os comprimentos da sua fila de mensagens e os logs quanto a problemas não entregues e problemas dessa natureza. Se a fila de entrega permanecer relativamente baixa, tudo bem.

Você pode obter informações médias de disco e de E / S da rede, mas se não encontrar problemas de entrega (enviei a mensagem quinze minutos atrás e ela ainda não chegou!) E você pode trabalhar no sistema via console ( ou ssh) sem muita latência, você deve ficar bem.

A média de carga é um valor que fornece uma idéia do número de processadores necessários ao kernel para poder executar todas as tarefas quando necessário, sem esperar.
No seu caso, se você tiver 2 ou mais CPU / Core. Não tem problema. Se você tiver apenas 1 CPU com 1 Core, significa que há um tempo "demais" entre o momento em que seu aplicativo deseja executar e o tempo em que o kernel o executa. Um carregamento> "número de CPU / núcleo" não será um problema para um sistema de correio até que atinja um valor muito alto por um período muito longo.
É claro que não há regra e valor a dar e, enquanto você recebe suas mensagens em pouco tempo, tudo bem. Mas você provavelmente precisará começar a olhar atentamente para o servidor quando a carga for superior a 2 * número de CPU / núcleo com muita frequência por um período 'longo' (~ 1 hora).
Novamente, para um servidor de email, isso não será um grande problema, mas começará a significar que o servidor está um pouco sobrecarregado.

Como sempre, com as questões relacionadas ao ajuste, não há respostas sim / não, tudo depende :-)

Dito isto, uma carga de 1,3 não parece alta, especialmente se você tiver uma configuração de CPU com vários núcleos. Se o número de carga for igual ao número de núcleos, todos os núcleos sempre terão um processo pronto para execução.

Por fim, se, como você diz, as mensagens estiverem sendo entregues em tempo hábil, o desempenho será bom :-)

top

fornecerá métricas básicas em tempo real o suficiente.

Uma média de carga menor que o número de CPUs que você tem significa que há outras que ficam sentadas sem nada para fazer. Igual significa que todos estão trabalhando no momento. Maior significa que existem processos que podem estar em execução, mas estão presos na fila de espera.

Para coisas super sensíveis ao tempo, como um servidor voip ou memcache, você deseja que seu load avg esteja bem abaixo do número de núcleos. Para coisas assíncronas que podem viver com o backup ocasional (como e-mail), você pode executar facilmente 4x o número de núcleos.

A maior ressalva a ser lembrada é que os processos que aguardam E / S de disco ou de rede, mas que são executáveis, ainda aparecem na média de carga. Portanto, se você tiver um servidor apache alimentando jpg de 56k usuários, poderá executar uma média de carga muito mais alta do que se tiver que disparar respostas php / script para um proxy / loadbalancer em uma LAN de gigabit. No seu caso, uma conexão smtp com algum servidor de correio lento que leva uma eternidade para transferir um anexo mostrará um processo 1 na fila de execução, mas pode ser interrompida vinte vezes para enviar um email rápido de uma linha para o gmail sem problemas.

O impulso é empurrado, a carga média é como a DOW. Na verdade, ele não mede de maneira alguma a "economia", as pessoas simplesmente a usam como uma métrica muito pouco correlacionada, porque é fácil falar sobre isso. Concentre-se no monitoramento das métricas com as quais você realmente se importa, como a profundidade da fila de entrega e as mensagens por segundo.

Quantos núcleos você possui? cat / proc / cpuinfo | processador grep | wc -l

(ressalva: o hyperthreading parece mais núcleos, mas não é)

Se o seu nível de carga estiver abaixo da contagem do processador, geralmente você está bem.

Dê uma olhada no topo e pressione '1' e você poderá assistir a carga individual de cada CPU.

Sim, isso é bastante aceitável e, geralmente, algo a ser esperado com um filtro de email.

Nossa configuração é um pouco diferente. Temos um servidor separado para SpamAssassin, enquanto nosso servidor POP executa o ClamAV para verificar a presença de vírus. O servidor POP geralmente está executando com uma carga de servidor de 2, mas ocasionalmente atinge até 10 ou mais. Nosso servidor SpamAssassin, por outro lado, costumava rodar em torno de 2 até instalar os filtros do Openprotect.com, quando duplicava o uso da CPU e agora está abaixo de 5 com picos acima de 15. Isso ainda é aceitável porque não há atrasos no correio que resultam em uma fila de correio crescente (usamos o qmail para SMTP recebido) e ainda há espaço para poupar o uso da CPU / memória.

Por coincidência, recomendo o Munin para monitorar seus servidores. Ele faz um ótimo trabalho ao demonstrar visualmente os dados históricos e mostrar quais recursos você tem de sobra. O monitoramento em tempo real com o Top (1) não ajuda muito. :)

Ah, e a propósito, implantar na sexta-feira antes do longo fim de semana é uma ótima maneira de trabalhar durante todo o fim de semana. Especialmente para sistemas críticos como um servidor de correio.

Como está o consumo de memória? É estável ou está crescendo?

A carga não parece fora da norma. Se o servidor de e-mail responder, e o e-mail estiver passando, eu diria que a única medida de falha além do consumo de memória seria se os e-mails errados estivessem sendo enviados (spam).

Lembre-se de que hoje seria o seu primeiro teste real. Provavelmente eu monitoraria levemente hoje. Se algo vai dar errado, agora seria a hora.