Есть ли способ узнать, какие процессы вызывают наибольшую загрузку ЦП?
У меня AMAZON EC2 Linux, загрузка процессора которого достигает 100 процентов и заставляет меня перезагружать систему. Я даже не могу войти через SSH (используя шпатлевку).
Есть ли способ узнать, что вызывает такую высокую загрузку ЦП и какой процесс это вызвал?
Я знаю о sar
и top
но мне нигде не удалось найти историю выполнения процесса. Вот изображение из инструмента мониторинга Amazon EC2, но я хотел бы знать, какой процесс это вызвал:
Я тоже пробовал ps -eo pcpu,args | sort -k 1 -r | head -100
но не удалось найти такую высокую загрузку процессора.
Есть несколько способов сделать это. Обратите внимание, что вполне возможно, что это вызывает множество процессов в сценарии сбоя, а не только один.
Первый способ - настроить pidstat для работы в фоновом режиме и получения данных.
pidstat -u 600 >/var/log/pidstats.log & disown $!
Это даст вам довольно подробный обзор работы системы с 10-минутными интервалами. Я бы посоветовал вам сделать это в первую очередь, поскольку он дает наиболее ценные / надежные данные для работы.
В этом есть проблема, в первую очередь, если блок переходит в цикл неконтролируемого процессора и производит огромную нагрузку - вы не гарантируете, что ваш фактический процесс будет выполняться своевременно во время загрузки (если вообще будет), поэтому вы действительно можете пропустить вывод !
Второй способ найти это - включить учет процессов. Возможно, более долгосрочный вариант.
accton on
Это включит учет процесса (если он еще не добавлен). Если до этого он не работал, потребуется время для запуска.
После запуска, скажем, 24 часов - вы можете запустить такую команду (которая выдаст такой результат)
# sa --percentages --separate-times
108 100.00% 7.84re 100.00% 0.00u 100.00% 0.00s 100.00% 0avio 19803k
2 1.85% 0.00re 0.05% 0.00u 75.00% 0.00s 0.00% 0avio 29328k troff
2 1.85% 0.37re 4.73% 0.00u 25.00% 0.00s 44.44% 0avio 29632k man
7 6.48% 0.00re 0.01% 0.00u 0.00% 0.00s 44.44% 0avio 28400k ps
4 3.70% 0.00re 0.02% 0.00u 0.00% 0.00s 11.11% 0avio 9753k ***other*
26 24.07% 0.08re 1.01% 0.00u 0.00% 0.00s 0.00% 0avio 1130k sa
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 28544k ksmtuned*
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 28096k awk
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 29623k man*
7 6.48% 7.00re 89.26% 0.00u 0.00% 0.00s
Столбцы упорядочены следующим образом:
Вы будете искать типы процессов, которые генерируют наибольшее количество пользовательского / системного времени ЦП.
Это разбивает данные как общее количество процессорного времени (верхняя строка), а затем как это время процессора было разделено. Учет процессов правильно учитывает только тогда, когда он включен, когда процессы запускаются, поэтому, вероятно, лучше всего перезапустить систему после включения, чтобы обеспечить учет всех сервисов.
Это никоим образом не дает вам четкого представления о том, какой процесс может быть причиной этой проблемы, но может дать вам хорошее представление. Поскольку это может быть 24-часовой снимок, существует вероятность искажения результатов, так что имейте это в виду. Он также всегда должен регистрироваться, поскольку это функция ядра и, в отличие от pidstat, всегда будет выводить данные даже при большой нагрузке.
Последний доступный вариант также использует учет процессов, поэтому вы можете включить его, как указано выше, но затем используйте программу lastcomm для получения некоторой статистики процессов, выполненных во время возникновения проблемы, вместе со статистикой ЦП для каждого процесса.
lastcomm | grep "May 8 22:[01234]"
kworker/1:0 F root __ 0.00 secs Tue May 8 22:20
sleep root __ 0.00 secs Tue May 8 22:49
sa root pts/0 0.00 secs Tue May 8 22:49
sa root pts/0 0.00 secs Tue May 8 22:49
sa X root pts/0 0.00 secs Tue May 8 22:49
ksmtuned F root __ 0.00 secs Tue May 8 22:49
awk root __ 0.00 secs Tue May 8 22:49
Это также может дать вам несколько подсказок относительно того, что может быть причиной проблемы.
Наверху - это особенно удобный демон для просмотра детализации на уровне процессов и по умолчанию архивирует эти данные в течение 28 дней. Помимо потрясающего интерфейса мониторинга в реальном времени, вы можете указать те файлы журналов, которые нужно открывать, и просматривать их.
В статья дает некоторое представление о возможностях, и вы можете найти больше в справочная страница.
Это действительно замечательная программа.
Такие программы как psmon и контролировать может быть полезно для вас. Они могут отслеживать процессы, запущенные в вашей системе, и если какой-либо порог (использование ЦП, использование памяти ...) будет превышен, вы можете настроить их на отправку вам по электронной почте отчета о том, что происходит.
Также можно автоматически перезапустить некорректно работающие процессы.
Одним из решений является написание сценария, который запускается через одну минуту cron или в цикле ожидания, и отправляет вам задание / дамп электронной почты / scp на том ebs ... с соответствующим выводом (dmesg, pstree -pa и ps aux, возможно vmstat) в тот момент, когда он обнаруживает, что средняя нагрузка превышает определенный предел ...