Вопрос или проблема
Когда я восстанавливаю архив tar или выполняю любую другую трудоемкую операцию с файловой системой, я замечаю, что kworker использует почти 100% ресурсов процессора, и операции, которые обычно выполняются за 10-15 минут, занимают неделю. Когда операция завершена, система выглядит нормально.
Это файловая система ext4 на LVM поверх mdadm.
Я выполнил несколько команд:
echo l > /proc/sysrq-trigger
И я наблюдал следующее:
[15858776.231727] Отправка NMI с CPU 3 на CPU 0-2,4-7:
[15858776.231738] Обратный след NMI для cpu 6
[15858776.231744] CPU: 6 PID: 32516 Команда: kworker/u16:4 Загрязнено: G T 6.6.13-gentoo #1
[15858776.231751] Название оборудования: Supermicro X9SRE/X9SRE-3F/X9SRi/X9SRi-3F/X9SRE/X9SRE-3F/X9SRi/X9SRi-3F, BIOS 1.0a 03/06/2012
[15858776.231755] Рабочая очередь: writeback wb_workfn (flush-252:4)
[15858776.231769] RIP: 0010:ext4_get_group_info+0x12/0x60
[15858776.231780] Код: 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 8b 87 38 05 00 00 3b 70 40 73 49 41 54 41 89 f4 55 <48> 89 fd 53 8b 88 b0 00 00 00 89
f3 48 8b 40 38 41 d3 ec 48 83 e8
[15858776.231785] RSP: 0018:ffffa91005d7f6e8 EFLAGS: 00000283
[15858776.231790] RAX: ffff901dd559f000 RBX: 0000000000000002 RCX: 0000000000000002
[15858776.231794] RDX: 0000000000000002 RSI: 000000000001dad5 RDI: ffff901dd55b1000
[15858776.231798] RBP: 000000000001dad5 R08: 0000000000000009 R09: 0000000000000300
[15858776.231801] R10: 0000000000000001 R11: 0000000000000000 R12: 000000000001dad5
[15858776.231804] R13: ffff901dc36fe098 R14: 0000000000000002 R15: ffff901dc8d4fc38
[15858776.231808] FS: 0000000000000000(0000) GS:ffff902cffd80000(0000) knlGS:0000000000000000
[15858776.231813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[15858776.231817] CR2: 000018c403504000 CR3: 0000000af6c2c005 CR4: 00000000000606e0
[15858776.231821] Вызов трассировки:
[15858776.231825] <NMI>
[15858776.231828] ? nmi_cpu_backtrace+0x84/0xf0
[15858776.231837] ? nmi_cpu_backtrace_handler+0x8/0x10
[15858776.231846] ? nmi_handle+0x58/0x150
[15858776.231853] ? ext4_get_group_info+0x12/0x60
[15858776.231860] ? default_do_nmi+0x69/0x170
[15858776.231870] ? exc_nmi+0xfe/0x130
[15858776.231878] ? end_repeat_nmi+0x16/0x67
[15858776.231889] ? ext4_get_group_info+0x12/0x60
[15858776.231896] ? ext4_get_group_info+0x12/0x60
[15858776.231903] ? ext4_get_group_info+0x12/0x60
[15858776.231910] </NMI>
[15858776.231912] <TASK>
[15858776.231914] ext4_mb_good_group+0x24/0xf0
[15858776.231922] ext4_mb_find_good_group_avg_frag_lists+0x89/0xe0
[15858776.231929] ext4_mb_regular_allocator+0x44e/0xe60
[15858776.231939] ext4_mb_new_blocks+0x9db/0x1040
[15858776.231948] ? ext4_find_extent+0x3bd/0x410
[15858776.231955] ext4_ext_map_blocks+0x382/0x1890
[15858776.231962] ? release_pages+0x122/0x3e0
[15858776.231971] ? filemap_get_folios_tag+0x1c5/0x1f0
[15858776.231983] ext4_map_blocks+0x18a/0x610
[15858776.231990] ? ext4_alloc_io_end_vec+0x15/0x50
[15858776.231997] ext4_do_writepages+0x74d/0xc80
[15858776.232007] ? preempt_count_add+0x65/0xa0
[15858776.232016] ext4_writepages+0xbd/0x1a0
[15858776.232026] do_writepages+0xc6/0x1a0
[15858776.232032] ? __schedule+0x2fb/0x890
[15858776.232041] __writeback_single_inode+0x3b/0x360
[15858776.232048] ? _raw_spin_lock+0xe/0x30
[15858776.232055] writeback_sb_inodes+0x1f9/0x4d0
[15858776.232064] __writeback_inodes_wb+0x47/0xe0
[15858776.232072] wb_writeback+0x265/0x2d0
[15858776.232080] wb_workfn+0x32c/0x4b0
[15858776.232087] ? _raw_spin_unlock+0xd/0x30
[15858776.232095] ? finish_task_switch.isra.0+0x8c/0x270
[15858776.232106] process_one_work+0x134/0x2f0
[15858776.232115] worker_thread+0x2f2/0x410
[15858776.232123] ? preempt_count_add+0x65/0xa0
[15858776.232130] ? _raw_spin_lock_irqsave+0x12/0x40
[15858776.232139] ? __pfx_worker_thread+0x10/0x10
[15858776.232146] kthread+0xf1/0x120
[15858776.232153] ? __pfx_kthread+0x10/0x10
[15858776.232158] ret_from_fork+0x2b/0x40
[15858776.232164] ? __pfx_kthread+0x10/0x10
[15858776.232169] ret_from_fork_asm+0x1b/0x30
[15858776.232180] </TASK>
Является ли вызов ext4_mb_find_good_group_avg_frag_lists признаком проблемы с фрагментацией, если нет, как я могу отладить эту проблему?
В /proc/mdstat не сообщается о проблемах, и я не вижу ошибок, связанных с /dev/sdX /dev/mdX, в журнале ядра.
Ответ или решение
Проблема с kworker/u16:4+flush-252:4: Фрагментация или что-то другое?
Ваше наблюдение о том, что kworker/u16:4+flush-252:4 потребляет почти 100% CPU во время выполнения тяжёлых файловых операций, таких как восстановление архива tar, вызывает беспокойство. Рассмотрим возможные причины замедления системы и, в частности, роль фрагментации файловой системы, учитывая ваши предоставленные данные, такие как использование файловой системы ext4, LVM и mdadm.
Анализ контекста
Наблюдения показывают, что высокая загрузка CPU вызвана работой в kworker, который управляет фоновой задачей записи данных. В выводе NMI-backtrace, который вы предоставили, можно увидеть, что система застревает на функции ext4_get_group_info и других вызовах, связанных с аллокацией блоков.
Функция ext4_mb_find_good_group_avg_frag_lists, как вы правильно заметили, может указывать на проблему с фрагментацией. FEHT (Filesystem Extent Handling Technology) в современных файловых системах, таких как ext4, направлена на минимизацию фрагментации при выделении блоков для хранения данных. Однако, если файловая система сильно фрагментирована, операции записи могут значительно замедляться, так как системе необходимо больше времени для нахождения и выделения фрагментов данных.
Влияние фрагментации на производительность
Фрагментация — это процесс, при котором блочные устройства (например, дисковые пространства) не заполнены равномерно. На ext4 это может привести к рассеянию данных по диску, что замедляет операции ввода-вывода. Существуют несколько признаков, которые указывают на наличие серьезной фрагментации:
- Медленные операции записи и чтения: Операции, которые должны выполняться быстро, могут занимать неоправданно много времени.
- Повышенная активность kworker: Увеличенное время выполнения задач
kworker/uпри работе с файловой системой. - Блокировки в функции аллокации: Как видно из вашего NMI-backtrace, вызовы функций связаны с аллокацией блоков и проверкой фрагментации, что также указывает на возможные проблемы.
Рекомендации по диагностике и устранению
Чтобы подтвердить или опровергнуть фрагментацию как причину вашего замедления системы, рекомендую следующие шаги:
-
Проверка фрагментации:
- Используйте команду
e2fsck -f /dev/your_partition, чтобы выполнить проверку и исправление ошибок в файловой системе. Обратите внимание на отчеты по фрагментации. - Запустите команду
tune2fs -l /dev/your_partition, чтобы получить информацию о степени фрагментации.
- Используйте команду
-
Дефрагментация файловой системы:
- В случае наличия фрагментации, можно рассмотреть возможность выполнения дефрагментации (хотя это не всегда прямолинейно на ext4).
- Перенос данных на временные устройства и затем возврат на оригинальное устройство может помочь в устранении фрагментации.
-
Мониторинг нагрузки системы:
- Используйте утилиты мониторинга, такие как
iotop,htopиatop, для выявления узких мест в производительности ввода-вывода.
- Используйте утилиты мониторинга, такие как
-
Обновление ядра и файловой системы:
- Убедитесь, что ваше программное обеспечение, включая ядро операционной системы и драйверы, обновлено до последней стабильной версии, поскольку многие проблемы с производительностью могут быть исправлены в новых релизах.
Заключение
Хотя вопрос о фрагментации является важным аспектом производительности файловой системы, не стоит исключать другие возможные причины, такие как проблемы с аппаратным обеспечением, неправильные настройки LVM или mdadm, или даже конфликты в системных службах. Следуя вышеизложенным рекомендациям и проводя систематический анализ, вы сможете более точно определить корень проблемы и принять необходимые меры для улучшения производительности вашей системы.