Investigação de Load alto

As médias de load no Linux são uma medida de quantos processos estavam utilizando a CPU (ou aguardando para usá-la) durante um determinado período de tempo, normalmente 1 minuto, 5 minutos ou 15 minutos.

Segue abaixo um exemplo de médias de Load:

Esses números dizem que a média de load foi de 1,05 no último minuto, 0,70 nos últimos 5 minutos e 5,09 nos últimos 15 minutos, respectivamente.

O que esses números dizem depende do sistema. Uma média de load de 5 em um sistema com um único núcleo de CPU significaria que havia no máximo 1 processo em execução e 4 esperando em média, ou seja, esse sistema estaria em overload. Uma média de load de 5 em um sistema com 8 núcleos de CPU significa que há no máximo 5 processos em execução em núcleos diferentes, com 3 núcleos ociosos. Esse sistema não estaria em overload.

Identificando um gargalo

De um modo geral, existem duas causas principais de overload:

• Existem muitos processos em execução.
• Os processos estão aguardando I/O.

Nesse caso, há mais processos em execução do que a CPU pode suportar, com isso ela não pode concluir a execução dos processos rápido o suficiente para evitar que vários processos precisem esperar pelo tempo da CPU.

Determinar o que está causando a carga é fundamental para qualquer investigação, e uma das ferramentas mais eficazes para fazer isso é o comando sar .

O pacote sysstat contém várias ferramentas úteis para investigar o desempenho e o uso em um sistema, entre eles o sar.  O sar formata os dados coletados pelo sysstat em intervalos regulares sobre várias partes do sistema. Como existem muitos dados coletados para serem efetivamente visualizados de uma só vez, o sar tem opções para especificar quais partes desses dados serão exibidas. Abaixo iremos detalhar algumas das opções mais úteis para nossa demanda:

Estatísticas de load

A  opção -q do sar mostrará dados sobre processos na fila e load. Aqui está o trecho relevante do manual:

• runq-sz: Tamanho da fila de execução (número de tarefas aguardando para execução).

• plist-sz: O número de tarefas na lista de processos.

Esta opção fornecerá uma visão geral do load ao longo do tempo. Quando o servidor está sobrecarregado, as médias de load aumentam assim como os valores em runq-sz e plist-sz . Os valores na coluna blocked geralmente aumentam significativamente apenas se o I/O for um fator, mas não é um indicador confiável de que o I/O é a causa da sobrecarga.

Deve-se tomar bastante cuidado na verificação desses dados. As médias de load em 10 não indicam overload se o servidor tiver 20 núcleos de CPU. 10 processos bloqueados quando há 100 processos na fila é diferente de 10 processos bloqueados com 1000 processos e nenhum indica realmente quanto tempo os processos aguardam o I/O.

Existem várias opções que exibem estatísticas para vários dispositivos de I/O, mas vamos detalhar a opção -d . A opção -d exibe estatísticas gerais para os discos rígidos. Segue o trecho da man page

O sar mostrará estatísticas para cada dispositivo. Se o servidor tiver várias unidades de disco, ele produzirá uma linha para cada dispositivo a cada intervalo. Por exemplo:

Esta saída mostra que existem duas unidades sda e sdb . É importante prestar atenção ao dispositivo e quais dados estão nesse dispositivo. Uma unidade de backup saturada causará problemas diferentes de uma unidade primária saturada.

Use a opção -p em conjunto com a -d opção para que os nomes dos dispositivos sejam exibidos da melhor forma.

O modo como cada um desses campos se relaciona ao load é muito menos claro, mas para fins de determinação da causa de overload, os campos await e %util são os mais significativos. Aqui estão as descrições desses campos novamente para dar ênfase.

%util é, em teoria, o mais direto dos dois. Se %util estiver próximo ou igual a 100%, o dispositivo está saturado. No entanto, se o dispositivo for uma matriz RAID, %util torna-se uma medida muito pior de saturação. Ainda é uma medida razoável da atividade geral de I/O e valores próximos a 100% ainda são um indicador de que pode haver um gargalo de I/O, mas não é tão fácil de identificar quanto em unidades únicas.

O campo await geralmente será a maneira mais confiável de identificar gargalos de I/O. Se os valores no campo tiverem mais 3 dígitos, haverá algum tipo de gargalo de I/O. Qualquer coisa maior que 50 é provavelmente um problema, mas valores menores como esse tornam dificultam a identificação. Geralmente, você terá que procurar outros sinais, como valores grandes no campo blocked , ou valores %util próximos a 100% em conjunto com await 50 +/- 20.

Estatísticas de memória

Embora o uso da memória não esteja relacionado a overload, as estatísticas da memória devem ser verificadas quando existirem indicações de saturação para a unidade primária. Especificamente, o sistema deve ser verificado quanto a sinais de thrashing. Thrashing é o termo para o que acontece quando um sistema quase esgotou sua memória e começa a mover rapidamente as páginas da memória da memória física para o disco e vice-versa. O thrashing aumenta a utilização do disco e geralmente leva a sobrecargas.

A opção geral para estatísticas de memória com o sar é a opção -r . Segue trecho do manual:

Esses campos não podem ser visualizados de forma isolada. Os campos de uso, kbmemfree , kbmemused , e %memused , mostram a quantidade de memória utilizada/disponível, mas não indica necessariamente que há um problema. A memória usada pelos buffers e cache, os campos kbbuffers e kbcached , respectivamente, podem ser descartados da memória para liberar memória para aplicações. De um modo geral, o uso de memória será próximo de 100% nos sistemas que estão fazendo uso efetivo de seu hardware.

O campo %commit pode ser um forte indicador de um problema, mas não há um limite claro. Uma boa regra geral é que qualquer valor acima de 200% é um problema, mas alguns sistemas podem ter problemas em 150% e às vezes valores próximos a 100%. Lembre-se sempre de analisar esse valor de acordo com o hardware do servidor.

Nenhum desses campos é um forte indicador de thrashing. O thrashing refere-se a páginas sendo movidas para dentro e para fora do disco, dentro e fora da swap. A opção -S exibe estatísticas sobre a utilização da swap. Segue trecho do manual:

Nenhum desses campos também é um forte indicador de trashing. Isso é incluído aqui para enfatizar que nenhum desses campos, inclusive %swpused , é um indicador de thrashing . Se o sistema estiver com thrashing , %swpused estará próximo de 100%, mas também estará próximo de 100% com frequência em sistemas sob condições perfeitamente normais. Se %swpused não estiver perto de 100%, é seguro dizer que o sistema não está com problemas. Se o servidor não possuir swap, ele não pode ter thrashing.

A opção -B exibe estatísticas de paginação (memória) e será uma boa opção se o sistema estiver com thrashing . Segue manual:

Vários desses campos podem ser usados ​​para indicar thrashing , mas o campo %vmeff geralmente é o único no qual você precisa prestar atenção. Este campo é uma medida da eficiência geral da memória virtual. Os valores aqui são idealmente exatamente 0,00 (significando que a memória virtual não foi acessada) ou quase 100,00 (a memória virtual foi acessada, mas não está causando problemas importantes ao sistema). Se o sistema estiver com trashing, %vmeff deve ser 30% ou inferior. Valores entre 30% e 70% são um tanto ambíguos, e esse campo deve ser analisado junto com outros campos para ajudar a determinar se o trashing está realmente ocorrendo.

Se você acredita que o sistema estava sobrecarregado como resultado do trashing e se estabilizou rapidamente, verifique em /var/log/messages se há registros de Out of Memory (OOM) Killer . Eles são uma forte indicação de que o sistema estava ficando sem memória e que o kernel precisou interromper um processo para liberar memória para evitar uma falha.

Resumo de verificações no sar: