Высокая загрузка процессора системой в Linux. Как узнать почему?

#linux #производительность #cpu

(источник: joxi.ru)

(источник: joxi.ru)    

Иногда имеем высокую загрузку процессора некими системными задачами.
Не процессами из userland, а именно "система" грузит.
Т.е. явно выполняются какие-то системные вызовы (выделение памяти, переключения контекста),
или работают драйверы (обрабатывают прерывания или что-то еще), идёт активный ввод-вывод. 

Это всё я всегда предполагаю, 
Но как узнать ТОЧНО, почему высокая загрузка - не представляю. Поэтому прошу помощи.  

Сейчас я использую несколько косвенных методов, но они не всегда подходят: глянуть
в iotop, прибвать процессы по одному, и смотреть не спала ли нагрузка.  

Но иногда просто нельзя останавливать сервисы. А иногда и процессов работающих уже
почти не осталось, а нагрузка всё равно есть. 

Вот хочется найти какое-нибудь средство быстро и точно узнавать что же грузит процессор.
    

Ответы

Ответ 1

Вам  


надо сходить сюда, можете найти русский перевод или похожие статьи. Поможет вам ограничить
выборочно потребление CPU процессами
почитать про strace и подобные ему 
sudo strace -t -e trace=open,connect,accept unity
сможете увидеть много интересного
для ядра - ftrace или поищите еще kernel tracer-ов


утилиты, которая дает понять это с одного взгляда я не знаю, если вы не нагуглите,
я бы пошел следующим способом: настроить мониторинг процессов так, чтобы в случае возникновения
нагрузки на K% на N секунд каким-либо процессом, он давал алерт. 

Можно наскриптовать так, чтобы при возникновении алерта, мониторинг натравливал trace
на этот процесс, на секунду, допустим, и сохранял бы список самых часто выполняемых
/ долгих функций. 

Но тут нужно быть осторожным, чтобы не повалить систему и не заполнить hdd. Т.е.
скриптинг должен учитывать, что необязательно ставить trace  на процесс, который уже
был под трейсом (т.е. для которого уже сохранен tracefile), иначе процессы начнут тормозить
еще больше, к примеру. Нельзя трейсить слишком долго - гигабайтные дампы вам не нужны. 

Если вы решаете конкретную задачу борьбы с DDoS - ну, или очень много денег и очень
много дц (повезло, если у вас есть), или cloudflare -  я бы так пошел для начала.

Т.е. тут все от задач зависит, дебажить драйвер ядра - один подход, защищаться от
ddos - другой.


Ответ 2

Красная полоска говорит о io-wait или о прерываниях. Это работа драйверов и ядра.

Откройте обычный top. Там будет строчка:

%Cpu(s): 15,3 us,  1,4 sy,  0,0 ni, 78,8 id,  3,4 wa,  0,8 hi,  0,3 si,  0,0 st


Если большое число перед wa - устройство ввода вывода работает медленней чем планировщик.
Чаще всего это запись на мертвый жесткий диск, но также может проявляться при работе
видеокарты (майнинг на gpu). Запись на сетевой диск.

hi и si это прерывания. Часто встречал при сгоревшей сетевой карте.

Дальше смотрим процессы в топе. Там или в квадратных скобках указан драйвер или без
них. Что-то вроде kworker/u8:7+events_unbound, loop8 и прочее. Название указывает на
что это такое и номер экземпляра. Покопавшись в /proc/, /sys/ можно сопоставить процесс
с устройством.

Стоит обратить внимания ещё и на обычные службы, которые могут хотеть от ядра слишком
многого. Например, ускорение шифрования на урезанном процессоре. Но там обычно полоски
наполовину зеленые, наполовину красные.

Ещё такие фокусы могут быть на виртуалках, когда другая виртуалка кушает ресурсы.