Використання процесора Linux та історія виконання процесів

Чи є спосіб дізнатися, який процес викликав найбільше використання процесора?

У мене є AMAZON EC2 Linux, використання CPU досягає 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 $!

Це дасть вам досить детальний прогноз роботи системи через десятихвилинні інтервали. Я б запропонував це бути вашим першим портом дзвінка, оскільки він створює найцінніші / надійні дані, з якими можна працювати.

У цьому є проблема, перш за все, якщо вікно переходить у відбійний цикл процесора і виробляє величезне навантаження - ви не гарантуєте, що ваш фактичний процес буде вчасно виконаний під час завантаження (якщо він взагалі є), щоб ви могли фактично пропустити вихід !

Другий спосіб шукати це - включити облік процесів. Можливо, більш довгостроковий варіант.

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. Час роботи CPU користувача
6. Відсоток
7. Час системного процесора.
8. Середні виклики вводу-виводу.
9. Відсоток
10. Назва команди

Що ви будете шукати - це типи процесів, які генерують найбільше часу користувача / системного процесора.

Це розбиває дані як загальну кількість часу процесора (верхній рядок), а потім про те, як розподілили цей час процесора. Облік процесів обліковується належним чином лише тоді, коли він увімкнено, коли процес нерестується, тому, ймовірно, найкраще перезапустити систему після того, як вона зможе забезпечити облік усіх послуг.

Це насправді не дає точного уявлення про те, який процес може бути причиною цієї проблеми, але може дати вам гарне відчуття. Як це може бути цілодобовий знімок, існує можливість перекосу результатів, тож майте це на увазі. Він також повинен завжди входити в систему, оскільки його функція ядра, на відміну від 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 та monit, можливо, вам корисні. Вони можуть контролювати процеси, що працюють у вашій системі, і якщо будь-який поріг (використання процесора, використання пам'яті ...) буде перевищено, ви можете встановити, щоб вони надсилали вам звіт про електронну пошту про те, що відбувається.

Також можливо автоматично перезапустити недобросовісні процеси.

Одне рішення - це написання сценарію, який запускається через одну хвилину або в циклі сну, і надсилає вам електронну пошту / scp завдання / дамп до тома ebs ... з відповідним результатом (dmesg, pstree -pa та ps aux, ймовірно vmstat) в той момент, коли він знаходить середнє навантаження за певну межу ...