Resposta bastante tardia, mas a resposta aceita ainda tem declarações incorretas, está faltando partes do ponto e sugere estatísticas, enquanto não há motivo aqui para não confiar naquelas relatadas pelo sistema operacional.
Aqui está uma explicação detalhada das estatísticas observadas.
A média de carga informada por uptime e outros comandos é uma média flutuante de 1 , 5 e 15 minutos da média número de encadeamentos aguardando uma CPU (fila de execução) mais o número médio de encadeamentos atualmente em execução em uma CPU.
A idéia é suavizar a exibição do tamanho da fila de execução e a contagem de processos em execução, que geralmente é muito irregular.
O tamanho da fila de execução é a primeira coluna da saída do vmstat ( r ). Qualquer valor diferente de zero significa que seu sistema teria rodado mais rápido se tivesse mais CPUs disponíveis.
A
vmstat primeira linha de dados mostra a média desde a última inicialização. Uma média de 3 threads estava esperando em sua máquina antes de você lançar vmstat . Este valor é geralmente insignificante sendo influenciado por longos períodos de inatividade, como finais de semana e outras horas não úteis:
r b w swap free re mf pi po fr de sr rm s0 s2 -- in sy cs us sy id
3 0 0 8747008 5562704 865 1866 188 63 63 0 0 -0 9 40 0 762 8588 1495 26 8 66
↑
Todas as outras amostras mostram uma fila de execução vazia, exceto a segunda última, que mostra um número médio enorme de threads 102 :
102 1 0 7717952 4979088 0 1 0 0 0 0 0 0 112 4 0 900 3464 7683 15 9 76
↑ ↑
A CPU está, todavia, 76% inativa durante essa amostra de 10 segundos, que é o que mais o intriga.
Para entender a aparente discrepância, você precisa entender que 102 é o valor médio para essa amostra. Uma maneira de obtê-lo é assumir que a fila de execução estava mantendo 1020 threads durante um segundo, depois estava vazia durante os 9 segundos restantes. Qualquer outra combinação que leve a esse número 102 também é concebível, como 204 threads durante 5 segundos e nenhum durante os outros 5, e assim por diante.
No entanto, de vmstat última coluna, sabemos que seu sistema estava 76% inativo durante esse período. Um valor plausível que acomoda a fila de execução média e a CPU inativa seria 408 encadeamentos competindo durante 2,4 segundos (CPUs ocupadas a 100%) e nenhum encadeamento ativo durante 7,6 segundos levando (0% de CPU ocupada).
Agora sabemos que definitivamente havia uma contenção de CPU. Se você tivesse mais de 408 CPUs disponíveis em vez de 2 e assumindo que todos os segmentos poderiam rodar a plena velocidade em paralelo, você teria reduzido estes 2.5 segundos para cerca de 6 ms . Isso teria um efeito dramático na aplicação interativa, mas não tanto em um trabalho em lote, pois o tempo restante não teria benefício das CPUs extras de qualquer maneira.
Linha de fundo:
Se a sua aplicação é interactiva, o seu sistema está seriamente sobrecarregado, se não estiver entre um pouco sobrecarregado e apenas "normal".
Há uma desvantagem a considerar, 6 ms é provavelmente "muito bom" para um tempo de resposta e 408 CPU é muito caro. Assumir que 60 ms é uma meta mais razoável, cerca de 40 CPUs podem funcionar e, claro, se 2.5 s estiver bem, seu sistema está se comportando corretamente.
Geralmente, uma boa prática é assumir que existe uma contenção quando o tamanho médio da fila de execução excede o número de CPUs, aqui ~ 37 vs 2. Descobrir se é um problema ou não, não pode ser feito sem analisar quais aplicativos e threads são afetados e como isso afeta a operação da plataforma.