Диск NVMe постоянная нагрузка 100%

Посмотрел "atop" и заметил загрузку диска от 95% до 100%.

Начал анализировать, все началось с того, что я отключил все работающие проекты на этом выделенном сервере и заметил, что нагрузка упала до `15-20%`, думал дело в проектах..но не тут то было там нагрузка снова вернулась и стала достигать `75-85%`, поверх было видно, что при появлении `kworker` нагрузка на диск моментально подскакивала.

скриншотыatop:

1. https://i.stack.imgur.com/r81Wr.png
2. https://i.stack.imgur.com/lsd8f.png
3. https://i.stack.imgur.com/nQ86t.png

Я смотрю в `perf log`, `perf top` и вижу:

https://i.stack.imgur.com/1VOxm.png
https://i.stack.imgur.com/KdXFa.png

Диски здоровы, результат по скорости:

1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.4319 s, 2.5 GB/s

Timing buffered disk reads: 3878 MB in 3.00 seconds = 1292.39 MB/sec


что можно сделать на следующих шагах, чтобы локализовать проблему и загруженности дисков на 95-100%?
Debian 10 debian 4.19.181-1

Лига Сисадминов

1.6K постов17.7K подписчиков

Добавить пост

Правила сообщества

Мы здесь рады любым постам связанным с рабочими буднями специалистов нашей сферы деятельности.

Вы смотрите срез комментариев. Показать все
2
Автор поста оценил этот комментарий
Я бы ковырнул параметры vm.dirty_ratio и backround_ratio. И ещё swapiness в 10% загнал для начала. Если своп вообще какому-то из процессов нужен, если нет - вообще в 1%
раскрыть ветку (20)
Автор поста оценил этот комментарий

vm.dirty_ratio=20
vm.dirty_backround_ratio=10

своп выключен в первую очередь. ситуация не изменилась.

раскрыть ветку (19)
1
Автор поста оценил этот комментарий

Норм, дефолты. Но я кажется знаю - там бага вроде как была, как раз наблюдалась на вашей версии ядра https://github.com/Atoptool/atop/issues/47

раскрыть ветку (18)
Автор поста оценил этот комментарий

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

раскрыть ветку (17)
1
Автор поста оценил этот комментарий
Ну, рискну предположить что либо свежее ядро либо свежий atop. В любом случае я бы для начала чекнул, есть ли реальная деградация производительности или метрики нагло врут. И если второе - мб и чёрт с ним?
раскрыть ветку (16)
Автор поста оценил этот комментарий

если врут метрики, конечно наплевать, вот и хочу проверить если ли реальная проблемы в связи с этими значениями?
поверхностно, все говорят, что все хорошо
perf top, скорость дисков и их здоровье, может еще что подскажете куда монжо посмотреть для понимания ситуации, есть ли потеря производительности или нет?
Порой ведь это может незаметно для меня администратора, но заметно для моих клиентов, но как у нас принято не сообщать или не замечать проблемы.
к тому же реально проблему можно не осознать, так как железо по факту простаивает ибо проект находится в бета-разработке и желаемого результата и статистики - не имею на руках. нет пиковых и средних значений.

раскрыть ветку (15)
1
Автор поста оценил этот комментарий
Можно ещё hdparm-ом тесты погонять, но надёжней всего ИМХО при нагруженной бд тем же sar-ом или iostat-ом смотреть очередь запросов к диску. Если диск реально заутилен на 100% - очередь будет существенная, 100 и больше.
раскрыть ветку (14)
Автор поста оценил этот комментарий

https://imgur.com/a/jVJMKAs

Числа прыгают от 65 до 100, причем прыгают они относительно закономерно как мне кажется.
Тоесть идет 65 - 86 - 92 - 96 - 99 - 100 - 65 (и так по кругу)
бывает конечно проскакивает 65 - 98 - 100 - 86

раскрыть ветку (13)
1
Автор поста оценил этот комментарий
Ну и ещё можно вот так посмотреть
while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done
нет ли какого-то гигантсктго райтбэка
раскрыть ветку (12)
Автор поста оценил этот комментарий
раскрыть ветку (11)
1
Автор поста оценил этот комментарий
Я на 90% уверен что атоп пиздит)
раскрыть ветку (10)
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку