Диск 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.5K пост17.7K подписчиков

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

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

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

o0svd00

2 года назад

Да чёрт не знает) Надо вникать

раскрыть ветку (1)

ThinTroll

2 года назад

Хорошо, спасибо, ты очень помог на самом деле.

показать ответы

jaskies

2 года назад

sudo apt-get install nmon

iotop

iostat -d 30 /dev/nvme1n1

sudo nvme smart-log /dev/nvme1n1 - temperature sensor 1

раскрыть ветку (1)

ThinTroll

2 года назад

https://github.com/netdata/netdata/issues/5744#issuecomment-...
нашел вот такую вот информацию, у меня в целом то такие же условия
NVMe + Ядро 4.19
Но я не осознаю, насколько это безопасно на рабочей машинке и какие последствия, изменения ожидаются.

показать ответы

jaskies

2 года назад

sudo apt-get install nmon

iotop

iostat -d 30 /dev/nvme1n1

sudo nvme smart-log /dev/nvme1n1 - temperature sensor 1

раскрыть ветку (1)

ThinTroll

2 года назад

1. (iotop) https://imgur.com/a/hRqesJX (на текущим скриншоте есть работающие проекты, есть скриншот с 18.05.2022, но без включенных проектов на машинке (нагрузка 75% через atop)), https://imgur.com/a/FpLYtjm
2. (iostat -d 30 /dev/nvme1n1)
3. (sudo nvme smart-log /dev/nvme1n1 - temperature sensor 1) https://imgur.com/a/h8bEHET

(sudo nvme smart-log /dev/nvme0n1 - temperature sensor 1)
https://imgur.com/a/BhO6z9D

У меня два диска в рейде

o0svd00

2 года назад

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

раскрыть ветку (1)

ThinTroll

2 года назад

Хм, на гитхабе обсуждались и даже существуют исправление этих показателей.
https://github.com/netdata/netdata/pull/10843

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

показать ответы

o0svd00

2 года назад

Шедулер - это не механизм ввода-вывода, это скорее механизм приоритизации.
Для ssd по идее нужен либо none, либо noop(оба по сути ничего не делают) т.к. они по сути эмулируют дисковое устройство а тот же cfq например писался с прицелом на нжмд. Но в целом ничего дурного не будет, дедлайн работает так что все запросы на чтение-запись прилетают в очереди по "секторам" к которым они обратятся и также ещё дополнительная очередь по дедлайну. Пока дедлайн запроса не наступил - планировщих идёт по секторам, если дедлайн случается - начинает разгребать очередь дедлайна пока не разгребёт все просроченные запросы. Таким образом он пытается обеспечить выполнение всех запросов за этот самый дедлайн. Всё это абсолютно бесполезно, т.к. ещё раз, то что видит система в случае ссд - это всего лишь эмуляция диска, но и большого вреда нанести не должно. Ещё можно row поставить(если доступен) - предельно тупой планировщик, которые всегда отправляет запросы на запись в конец очереди.

раскрыть ветку (1)

ThinTroll

2 года назад

Тоесть, визуально это решает проблему, но по факту она остаётся?
я много раз читал, что необходимо оставлять none, но нашел ответы на гитхаб, где советуют поставить так и в целом это решило проблему человеку, но для себя пока не знаю как поступить, возможно стоит обновить ядро стандартными методами и посмотреть что будет.
https://wiki.debian.org/HowToUpgradeKernel

показать ответы

o0svd00

2 года назад

Можно попробовать ещё прошивку контроллера обновить на ссд, но это чаще всего нужна винда и физический жоступ к машинке

раскрыть ветку (1)

ThinTroll

2 года назад

Исправил метод ввода/вывода с none на mq-deadline, нагрузка ушла вообще.
но пока не могу оценить, как это влияет на работу сервера

echo mq-deadline > /sys/block/nvme0n1/queue/scheduler

echo mq-deadline > /sys/block/nvme1n1/queue/scheduler

показать ответы

jaskies

2 года назад

думаю без накатки нового ядра не обойдется все делать на тестовой машинке

раскрыть ветку (1)

ThinTroll

2 года назад

как понять на тестовой машинке?
У меня только дедик с продом, что за методы такие?
как мне где-то в другом месте повторить подобные условия?

показать ответы

o0svd00

2 года назад

Я на 90% уверен что атоп пиздит)

раскрыть ветку (1)

ThinTroll

2 года назад

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

показать ответы

o0svd00

2 года назад

Ну и ещё можно вот так посмотреть
while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done
нет ли какого-то гигантсктго райтбэка

раскрыть ветку (1)

ThinTroll

2 года назад

https://imgur.com/a/Tethmcd
нулевой

показать ответы

o0svd00

2 года назад

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

раскрыть ветку (1)

ThinTroll

2 года назад

https://imgur.com/a/jVJMKAs

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

показать ответы

o0svd00

2 года назад

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

раскрыть ветку (1)

ThinTroll

2 года назад

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

показать ответы

o0svd00

2 года назад

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

раскрыть ветку (1)

ThinTroll

2 года назад

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

показать ответы

o0svd00

2 года назад

Я бы ковырнул параметры vm.dirty_ratio и backround_ratio. И ещё swapiness в 10% загнал для начала. Если своп вообще какому-то из процессов нужен, если нет - вообще в 1%

раскрыть ветку (1)

ThinTroll

2 года назад

vm.dirty_ratio=20
vm.dirty_backround_ratio=10

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

показать ответы