Estou diagnosticando um evento de alto uso da CPU e encontrei uma diferença estranha entre os números de ps/vmstat
, que mostram quase 0%, e sar/top
, que mostram quase 100% (usuário + sistema):
sar 1 5
Linux 2.6.9-67.ELsmp (uxdfl712) 07/25/2020
01:48:31 PM CPU %user %nice %system %iowait %idle
01:48:32 PM all 43.83 0.00 56.17 0.00 0.00
01:48:33 PM all 42.68 0.00 57.32 0.00 0.00
01:48:34 PM all 42.57 0.00 57.43 0.00 0.00
01:48:35 PM all 43.18 0.00 56.82 0.00 0.00
Average: all 43.14 0.00 56.86 0.00 0.00
vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
32 0 0 10493612 233320 4485160 0 0 0 14 0 1 0 0 100 0
ps -e hao %cpu | awk '{ sum += $1 } END { print sum }'
0.2
top -bn 1 |
sed '1,/PID USER PR NI %CPU/d' |
awk '{ sum += $5 } END { print sum }'
398
Pesquisei muito no StackExchange e em outros lugares, mas tudo o que encontrei foram referências sobre coisas de virtualização (esta é uma máquina física) e carga da CPU, o que não é meu problema. Eu também verifiquei /proc/<PID>/stat
, mas não encontrei nenhuma dica sobre isso.
Por que esses comandos mostram números diferentes? Eles estão realmente consultando coisas diferentes? Ou os executáveis podem ser muito antigos e com bugs (por favor, veja os dados do servidor abaixo - estou realmente horrorizado com o quão desatualizado isso é).
Obrigado!
uname -r
2.6.9-67.ELsmp
cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 6)
yum provides `which sar` | grep installed
sysstat.i386 5.0.5-16.rhel4 installed
yum provides `which vmstat` | grep installed
procps.i386 3.2.3-8.9 installed
yum provides `which ps`
<Too many providers>
ps -V
procps version 3.2.3
yum provides `which top` | grep installed
procps.i386 3.2.3-8.9 installed
grep -c processor /proc/cpuinfo
4
Esta é uma carga intermitente e ocasional. A primeira linha de vmstat
gives averages since the last reboot
, que aparentemente neste host está ociosa. As linhas subsequentes mostram dados para o período de amostragem, que será mais próximo do que o sar está relatando.0% ocioso por um longo período de tempo geralmente não é bom. Mas o quão ruim é ficar sem CPU realmente depende do sistema e dos aplicativos.
Avalie o desempenho dos aplicativos nesta caixa. Como é o tempo de resposta às solicitações dos usuários? Está fazendo o processamento em lote a tempo? Se suas expectativas de desempenho não forem atendidas, essa é uma razão para melhorar as coisas.
Além da idade do hardware, este é um software mais antigo; O RHEL 4 entrou no suporte estendido há 8 anos. Em um Linux moderno, é fácil encontrar exatamente o que está na CPU. Instale símbolos de depuração e execute
perf top
. E qualquer coisa pode ser instrumentada em detalhes. No entanto, não me lembro de quão boas eram as ferramentas de desempenho no RHEL 4.Realmente, se esse host continuar a fornecer valor, ele deve ser atualizado. Para obter atualizações de segurança novamente, se nada mais.