Я диагностирую событие высокой загрузки ЦП и обнаружил странную разницу между числами из ps/vmstat
, которые показывают почти 0%, и sar/top
, которые показывают почти 100% (пользователь + система):
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
Я много искал в StackExchange и в других местах, но все, что я смог найти, это ссылки на виртуализацию (это физическая машина) и загрузку процессора, что не является моей проблемой. Я также проверил /proc/<PID>/stat
, но не нашел намеков на это.
Почему эти команды показывают разные числа? Действительно ли они запрашивают разные вещи? Или исполняемые файлы могут быть слишком старыми и глючными (см. Данные сервера ниже - я действительно в ужасе от того, насколько это устарело).
Спасибо!
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
Это периодическая, периодическая нагрузка. Первая строка vmstat gives averages since the last reboot
, который, видимо, на этом хосте в основном простаивает. Последующие строки показывают данные за период выборки, который будет ближе к тому, что сообщает sar.
0% простоя в течение длительного периода времени, как правило, нехорошо. Но насколько сильно не хватает ЦП, зависит от системы и приложений.
Оцените, как приложения работают в этом блоке. Как время ответа на запросы пользователей? Выполняется ли пакетная обработка вовремя? Если ваши ожидания производительности не оправдались, это повод для улучшения.
Помимо возраста оборудования, это более старое программное обеспечение; RHEL 4 получил расширенную поддержку 8 лет назад. В современном Linux найти именно то, что стоит на ЦП, легко. Установите символы отладки и запустите perf top
. И все, что угодно, можно детально оснастить. Однако я не помню, насколько хороши были инструменты производительности в RHEL 4.
На самом деле, если этот хост должен продолжать предоставлять ценность, его следует обновить. Чтобы снова получить обновления безопасности, если ничего другого.