Очень странная ситуация с дисками NVMe

Тоже недавно была проблема с этими дисками. Но у меня сервера на Windows.

Dimanych, Сделайте fstrim и посмотрите, поможет или нет.

fstrim - Делал, не помогло, совершенно не повлияло.

Сейчас немного продвинулся дальше и понимаю прямую зависимость % нагрузки на диск и что её вызывает. % равен примерно очереди вызовов на запись диска.

wrqm The number of write requests merged per second that were queued to the device. Также команда iostat -d -x 1 - показала мне что есть всплески записи по 15мб в сек, чего все другие включая atop не показывают. Правда что такое 15мб в сек для NVMe ... Есть над чем подумать.

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

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

Возможно стоит оптимизировать mysql, чтобы больше памяти потребляла, а не кушала ресурсы диска.

Да я тоже не раз думал о том, что достиг какого то iops по диску и теперь состояние перегрузки и очереди, поэтому и держится всегда 100%. На то что проблемы с самими дисками я не думаю, так как они оба одинаково подгружены, а обычно вылетает 1 из.

Размышляя о том какие процессы пишут на диск.

журнал иногда срабатывает на 10мб запись

mysql, но достаточно редко 1-2 мб.

nginx - тут скорее всего загрузка файлов в сервис, изредка прыгает до 10мб, иногда тишина.

Прочие процессы, точно также лишь изредка что-то пишут не более 1мб.

Дело в том что все эти процессы одновременно диск не напрягают, а лишь скачками.

По поводу чтения я как раз масимально оптимизировал iops, чтение проходит примерно по 10-15кб одним процессов за один подход каждую секунду. Что это такое для NVMe ? Это очень маленькая нагрузка. У меня раньше и обычные диски 100-150 iops подобного чтения держали без перегрузки. Уже частично останавливал некоторые процессы nginx / mysql, картина сильно не менялась. Все службы остановить не могу, клиенты сожрут. Запись в логи также отключал, нет эффекта.

Я уже думаю может драйвера виноваты или ещё что, с обновлением на debian 10...

Ещё вариант, atop неверно рассчитывает нагрузку на диски, хотя avio тоже велик.

Сколько занято на дисках? Есть софтовый RAID? Смотрели blktraceом что именно происходит в эти моменты, кто и что делает с дисками?

именно в этом и дело. все остальное в норме

https://www.master-x.com/forum/postings/3419089/#3419089

danforth, занято не очень много, может 400гб, raid1 можно сказать 1 раздел на всю систему. blktrace, ни разу не использовал, надо изучить будет.

Проверил, выплёвывает бинарные данные и названия файлов, пока не знаю как разобрать:

blktrace -w 30 -d /dev/nvme0n1 -o-

EvGenius, это интересно, у него тоже debian10. Есть одно но, проверяю с соседнего сервера загрузку файла по wget, скорость проседает иногда до 10мб в сек. Не может быстро сбрасывать на диск, так как полоса не забита. Если же другим сервером качаю, то почти всегда стабильно 80-100мб - т.е. выкачивает весь гбит. Также есть жалобы пользователей, что иногда файл на сервер загружается медленно.

Да, это очень похоже на мою ситуацию, буду разбираться

https://github.com/Atoptool/atop/issues/47

---------- Добавлено 29.04.2020 в 21:44 ----------

EvGenius Спасибо за наводку.

Действительно баг присутствует на уровне кернеля для nvme дисков и как раз debian 10 и другие дистрибутивы с этим тоже столкнулись. Решение, не обращать внимания или обновляться до кернел 5.2. Жаль потраченные 2 дня, на эту проблему.

Если кому ещё интересно, тут много инфы в ответе:

https://serverfault.com/questions/1000901/nearly-100-disk-utilization-after-upgrading-to-debian-10-without-any-reason

Ещё покопался, кто столкнётся, решение до безумия простое, и теперь busy 0-5% у дисков :)

Оказывается по умолчанию для NVMe sheduler [none]. Видать в таком режиме не те данные передаёт для утилит.

Ну и это конечно не отменяет бага kernel.