Load Average no Linux

Na administração de servidores Linux o load average é quase instintivamente consultado, essa preocupação se deve ao fato da carga do sistema ser uma métrica usada para medir e dimensionar  servidores e seus trabalhos, vale lembrar que muitas vezes lidamos com instâncias em nuvem e neste ambiente o load average pode significar economia ou prejuízo a depender das métricas utilizadas.

Embora seja um assunto muito bem documentado, vou  me aventurar um pouco nele também. Abaixo uma imagem de load average gerada pelo monitoramento do Zabbix ao longo de sete dias de um servidor Oracle.


É possível observar picos regulares causados devido a uma rotina de backup agendada no cron, embora não exista a informação da quantidade de CPUs este histórico nos indica um consumo padrão muito abaixo dos picos. Processos em espera devido ao atraso de IO de um HD externo faz o load average subir, mas não por um gargalo do processador mas sim pelas limitações da USB ou do disco.

No Linux podemos ver load average através de vários comandos, dois deles são o uptime e o top.

Os dois comandos fazem a mesma impressão da informação da carga do sistema, abaixo o primeiro deles o "uptime" mostra o load average. São apresentados 3 números representando a média de processos rodando ou em espera pelo processador  nos últimos 1, 5 e 15 minutos.


Nesta saída do uptime e podemos concluir que existem 0,97 processos em execução e/ou esperando no último minuto e que está havendo um crescimento em comparação com os últimos 5 e 15 minutos.


Na saída do top confirmamos que o load segue baixo agora em 0,47, com tendência de queda se observamos os últimos 5 e 15 minutos. Na mesma tela a linha CPU(s) um pouco abaixo podemos verificar que o wait está em 0.0%, bem alinhado com o resultado do load, assim como o idle bem alto 97,2% confirmam que o servidor está bem ocioso.

Mas olhando apenas o load average muitas vezes não podemos concluir muita coisa além da tendência de subida ou queda de carga, mas a partir do momento que se conhece o número de CPUs podemos ter uma visão mais clara.

lscpu - Mostra informações detalhadas de CPU.


Conhecendo o número de CPUs percebemos que o servidor está realmente muito ocioso, para 32 CPUs mesmo um load de 32 poderia não significar um problema, caso ele estivesse apenas esperando para gravar um subprocesso limitado à velocidade de um hd externo por exemplo.

Acredito que dentro da funcionalidade básica deste recurso para por aqui já é o suficiente, contudo não poderia deixar de falar sobre algumas curiosidades que achei numa pesquisa pelo Google .

Curiosidades

A primeira é sobre s RFC 546 de 1973 descrevendo uma análise de load average nos dinossauros BBN-TENEX e USC-ISI. 

Fonte: http://tenex.opost.com/kapix.html

O climax fica por conta do gráfico das cargas feito a mão.


Trecho da RFC interpretando o gráfico:

  Interpreting data such as this is tricky business.  However, it is   difficult to resist making the following observations:
   1. The shapes of the BBN and ISI curves are approximately the; furthermore, there is no skew between the curves.  This suggests      that the user populations for the two systems have similar working      habits and are acclimated to the same time zone.


   2. The significant features of both curves appear to be strongly correlated with "normal events" in the day of a user living on      East Coast time,suggesting that the load at both sites is      influenced most strongly by such users:
      a. the load begins to increase between 7-8 a.m. EDT as users begin their daily computing;
      b. it dips between 10-11 a.m. EDT (smoothed to a smaller rate of increase in the ISI curve) as users take their coffee break;
      c. the load peaks sharply between 1-2 p.m. EDT as users return from lunch to resume their computing;
      d. it decreases as the afternoon continues and as users go home from work;
      e. it reaches a local minimum between 6-7 p.m. EDT (minimum not present in ISI curve) when most people eat dinner;
      f. it increases to an evening peak between 9-10 p.m. EDT as some users come back from dinner and after dinner activities to         resume their computing.


   3. The curve for ISI is smoother than the one for BBN: the "coffee      break" dip appears only as a decrease in slope; the dinner break      and evening peak are completely smoothed  out.  This smoothing is      probably due to the influence of the West Coast users of the ISI      machine.


   4.  During July the BBN system was more heavily loaded than the ISI system.  Since the data collected did not include the number of      active jobs it is not possible to determine from the data whether      BBN had more users or just more demanding users."



Postagens mais visitadas