обнаружить процесс, поглощающий ресурсы процессора без: top, htop, ps?

обнаружить процесс, поглощающий ресурсы процессора без: top, htop, ps?

Я столкнулся с проблемой, когда мог только догадываться, какой процесс потребляет ресурсы процессора.

Загрузка моего процессора составляла около 80% для всех ядер в psensor.

Я пробовал htop, topи ps -A -o pcpu,pid,cmd --sort +pcpu(последний я даже пробовал с sudo, но безрезультатно).
Все они показали виновный pid (о котором я знал), используя около 7% всего...

Когда я подаю сигнал SIGKILL на этот pid, все возвращается в норму.

Для проверки я создал бесконечный цикл на терминале while true;do echo -n;done, но это было ясно видно в htop; поэтому мое предположение о том, что именно вызывало проблему, было не таким...

Вот мне интересно, есть ли другие способы найти виновника, не гадая?

Подумав еще раз, я думаю, что мне было бы интересно узнать, какие вычисления psensorи какие «апплеты индикатора загрузки системы» используют, чтобы показать это значение, а другие — нет?

P.S.:ссылка о времени ожидания, ссылка о средней нагрузке

решение1

Я не настолько хорошо знаком с деталями, чтобы дать точные подсказки, но предполагаю, что есть два источника различий между реальной вызванной нагрузкой и отображаемым использованием ЦП:

  1. Процесс может состоять из нескольких потоков и topне суммировать их. Количество потоков можно посмотреть по этому:

    ps -eo pid,nlwp,%cpu,user,args
    

    В topвы можете переключить обработку потоков с помощью H. Загрузка ЦП каждым потоком обычно довольно низкая.

  2. Процесс может вызывать много ввода-вывода. Время ожидания ввода-вывода является частью общей загрузки ЦП, но может не быть частью значения использования ЦП процессом. Поэтому проверьте значение waitв top. Оно не сообщает вам, какие процессы вызывают его в какой степени, но если значение низкое, то оно не может объяснить эффект.

решение2

Код, выполняемый в системе unix, классифицируется как код ядра или код пользовательской области. Код пользовательской области всегда прикреплен к процессу, поэтому, если ЦП занят выполнением кода пользовательской области, это отображается в некоторой строке в top. Код ядра обычно прикреплен к процессу: если ядро ​​выполняет системный вызов, то обработка в ядре считается принадлежащей этому процессу. Время ядра — это «системное время», сообщаемое утилитой time.

Некоторые из действий ядра не могут быть напрямую отнесены к одному процессу. В частности, аппаратные прерывания по сути не принадлежат конкретному процессу. Например, предположим, что прерывание вызвано сетевой картой. Ядро выполняет код для чтения и анализа сетевого пакета; пока ни один процесс не участвует. Пакет может быть отклонен правилом брандмауэра, и в этом случае ни один процесс не может претендовать на это время обработки. Если процесс в конечном итоге получает этот пакет, часть времени приема будет помещена на вкладку этого процесса, но не на ранних стадиях.

Таким образом, возможно иметь процессорное время, которое не принадлежит ни одному процессу. Однако иногда это процессорное время косвенно вызвано каким-то процессом. Например, если есть процесс, который отправляет пакеты на другую машину и заставляет эту другую машину отвечать, но брандмауэр блокирует ответные пакеты, то время, потраченное на анализ и отбрасывание ответных пакетов, не будет отслежено до этого процесса отправки; но если процесс отправки останавливается, что приводит к тому, что удаленная машина перестает отвечать, то ядро ​​больше не будет тратить время на отклонение пакетов. Конечно, сеть — это только один пример, есть много других способов, которыми ядро ​​может делать вещи, которые нельзя отследить напрямую до одного процесса.

Вы не предоставили достаточно информации, чтобы быть уверенным, что происходит именно это (и это может быть сложно понять без отладчика ядра), но это правдоподобное объяснение.

решение3

Если вы не хотите использовать htop,ps,top, вы можете использовать systemtap для получения более низкоуровневой информации.

Связанный контент