В прошлую пятницу я обновил свой сервер Ubuntu до 11.10, который теперь работает с ядром 3.0.0-12-server. С тех пор общая производительность резко упала. До обновления загрузка системы составляла около 0,3, но в настоящее время она составляет 22-30 в 8-ядерном ЦП с 16 ГБ ОЗУ (10 ГБ свободно, без подкачки).
Я собирался обвинить драйвер файловой системы BTRFS и нижележащий массив MD, потому что [md1_raid1] и [btrfs-transacti] потребляли много ресурсов. Но все [kworker / *: *] потребляют намного больше.
sar выдает что-то похожее на это постоянно с пятницы:
11:25:01 CPU %user %nice %system %iowait %steal %idle
11:35:01 all 1,55 0,00 70,98 8,99 0,00 18,48
11:45:01 all 1,51 0,00 68,29 10,67 0,00 19,53
11:55:01 all 1,40 0,00 65,52 13,53 0,00 19,55
12:05:01 all 0,95 0,00 66,23 10,73 0,00 22,10
И iostatподтверждает очень плохую скорость записи:
sda 129,26 3059,12 614,31 258226022 51855269
sdb 98,78 24,28 3495,05 2049471 295023077
md1 191,96 202,63 611,95 17104003 51656068
md0 0,01 0,02 0,00 1980 109
Вопрос: как я могу отследить, почему потоки kworker потребляют так много ресурсов (и какой именно)? Или лучше: это известная проблема с ядром 3.0, и можно ли настроить его с параметрами ядра?
Редактировать:
Я обновил ядро до новой версии 3.1, как рекомендовано разработчиками BTRFS. Но, к сожалению, это ничего не изменило.
источник
pcie_ports=compatилиpcie_ports=native. (Попробуйте сначала «родной». Менее вероятно, что проблема будет решена, но менее вероятно, что она вызовет другие проблемы.)Ответы:
Я нашел эту ветку на lkml, которая немного отвечает на ваш вопрос. (Кажется, даже сам Линус был озадачен тем, как выяснить происхождение этих нитей.)
По сути, есть два способа сделать это:
Для этого вам понадобится скомпилировать ftrace в вашем ядре и включить его:
Дополнительная информация о средствах трассировки функций в Linux доступна в документации ftrace.txt .
Это выведет, что все потоки делают, и полезно для отслеживания нескольких небольших заданий.
Это выведет стек одного потока, выполняющего большую работу. Это может позволить вам выяснить, что послужило причиной того, что этот конкретный поток перегружает процессор (например).
THE_OFFENDING_KWORKERpid kworker в списке процессов.источник
-EУдачное предположение заставило меня попробовать опцию сна, и использование процессора исчезло!Решение: я не знаю, как найти причину. Пока никто не сказал мне.
Но общение с разработчиками BTRFS выявило ошибку в драйверах btrfs при записи большого количества маленьких файлов за очень короткий промежуток времени. Это проблема с ядрами от 3.0 до 3.1. Возможно это исправлено в 3.2.
Тем временем я получил патч для текущего ядра, который решил проблему.
источник
У меня была похожая проблема; глядя на стек потоков kworker:
Я понял, что это USB-модули. Раньше на другой машине я беззаботно rmmod делал все модули usb и [uex] hci, понимая, что я выключил клавиатуру (даже не ctrl-shift-sysrq-U!), Так что в итоге я сделал это:
сделал трюк:
Поэтому мой главный подозреваемый - это гаджет: RTL8723B * WIFI + модуль Bluetooth. Теперь мне интересно, понимает ли код управления питанием, что это то же самое устройство, если оно пытается, например, выключить неиспользуемый адаптер BT.
контекст:
источник
echo N >/sys/module/drm_kms_helper/parameters/poll(в режиме root)Проблема с графической картой Intel
источник