Назад | Перейти на главную страницу

Использование ЦП Linux и история выполнения процессов

Есть ли способ узнать, какие процессы вызывают наибольшую загрузку ЦП?

У меня 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    

Столбцы упорядочены следующим образом:

  1. Количество звонков
  2. Процент звонков
  3. Количество реального времени, затраченного на все процессы этого типа.
  4. Процент.
  5. Время ЦП пользователя
  6. Процент
  7. Системное процессорное время.
  8. Среднее количество вызовов ввода-вывода.
  9. Процент
  10. Имя команды

Вы будете искать типы процессов, которые генерируют наибольшее количество пользовательского / системного времени ЦП.

Это разбивает данные как общее количество процессорного времени (верхняя строка), а затем как это время процессора было разделено. Учет процессов правильно учитывает только тогда, когда он включен, когда процессы запускаются, поэтому, вероятно, лучше всего перезапустить систему после включения, чтобы обеспечить учет всех сервисов.

Это никоим образом не дает вам четкого представления о том, какой процесс может быть причиной этой проблемы, но может дать вам хорошее представление. Поскольку это может быть 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) в тот момент, когда он обнаруживает, что средняя нагрузка превышает определенный предел ...