| wau |
|
|
Темы:
132
Сообщения:
956
Участник с: 11 октября 2013
|
С месяц как приехал из "отпуска" и обновился. Сразу зашумел вентилятор - 100% загрузка одного ядра процессом от рута kworker/u16:2+events_unbound. Системный раздел btrfs. Взлетает после накатывания обновлений. Обычно не дожидался угасания, отправлял в перезагрузку (типа ядро ведь обновлялось). Но таки беспокоит. Вот сейчас сижу, ничего не обновляю, черчу чертежи. Взлетел. Пока писал - погас. Отпостил - вот снова взлетел. Это неормальное поведение. Какие будут мнения? |
| vasek |
|
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
wauАнализировать!!! чтобы определить виновника .... основной инструмент - perf - Call Trace PS - иногда причина в збесившемся прерывании ACPI - поверь: grep . -r /sys/firmware/acpi/interrupts - обычно имеет значение сотни тысяч
Ошибки не исчезают с опытом - они просто умнеют
|
| wau |
|
|
Темы:
132
Сообщения:
956
Участник с: 11 октября 2013
|
Случается (других поводов не помню потому и) только после того, как приму обновления и не перезагружусь. |
| vs220 |
|
|
Темы:
22
Сообщения:
8070
Участник с: 16 августа 2009
|
А |
| vasek |
|
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
Анализ kworker - в кратце ... PS - 100% надежды, что быстро найдешь виновника нет - здесь нужно очень хорошо разбираться в этих выводах, а это не так то и просто … но иногда, если причина в модуле, то это помогает … но запускать всеравно нужно. 1. perf В момент, когда kworker грузит cpu, запустить сбор данных, например, на 10с - sudo perf record -g -a sleep 10 дождаться окончания процесса, а после запустить команду - sudo perf report Смотри, что замалевано красным, перемещение вниз/вверх - соотвествующие стрелки, вправо/влево - соотвествующие стрелки. Нажатие e на выбранной строке - более детальная информация, для возврата - нажать c. Последняя колонка: [ k ] - процес в пространстве ядра, [ . ] - процес в пространстве user. PS - В принципе можно пойти и дальше, но лучше не ходить: на выбранной строке нажимаем Enter - выбираем нужное - снова Enter - выход Esc 2. Обратная трассировка В момент, когда kworker грузит cpu, запустить команду - # echo l > /proc/sysrq-trigger ... и после смотри вывод dmesg, для каждого ядра будет вывод Call Trace, в котором возможно увидишь намек на причину - это будет или модуль или библиотека или что другое. EDIT - для полноты картины, решил добавить kernel kworker debug - согласно DOC ... пусть уж все будет в одном месте Если kworkers сходят с ума (слишком нагружают cpu), есть две возможные причины проблемы (привожу без перевода): # echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event # cat /sys/kernel/debug/tracing/trace_pipe > /…/kworker_debug.txt ... имя файла любое ждем несколько секунд для набора данных и завешаем процесс (Ctrl+C) ... и как пишут # cat /proc/<PID>stack ... где <PID> - PID взбесившегося процесса kworker (узнать можно и так - sudo ps aux | grep kworker) Это выведет стек одного потока, выполняющего много работы, что может помочь выяснить, что заставило этот конкретный поток загружать процессор.
Ошибки не исчезают с опытом - они просто умнеют
|
| wau |
|
|
Темы:
132
Сообщения:
956
Участник с: 11 октября 2013
|
vs220 процесс от рута kworker/u16:2+events_unbound |
| wau |
|
|
Темы:
132
Сообщения:
956
Участник с: 11 октября 2013
|
vasek Спасибо, вооружен - теперь буду ждать очередного взлета. |