Ещё покопался, кто столкнётся, решение до безумия простое, и теперь busy 0-5% у дисков :)
Оказывается по умолчанию для NVMe sheduler [none]. Видать в таком режиме не те данные передаёт для утилит.
Ну и это конечно не отменяет бага kernel.
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
Да я тоже не раз думал о том, что достиг какого то iops по диску и теперь состояние перегрузки и очереди, поэтому и держится всегда 100%. На то что проблемы с самими дисками я не думаю, так как они оба одинаково подгружены, а обычно вылетает 1 из.
Размышляя о том какие процессы пишут на диск.
журнал иногда срабатывает на 10мб запись
mysql, но достаточно редко 1-2 мб.
nginx - тут скорее всего загрузка файлов в сервис, изредка прыгает до 10мб, иногда тишина.
Прочие процессы, точно также лишь изредка что-то пишут не более 1мб.
Дело в том что все эти процессы одновременно диск не напрягают, а лишь скачками.
По поводу чтения я как раз масимально оптимизировал iops, чтение проходит примерно по 10-15кб одним процессов за один подход каждую секунду. Что это такое для NVMe ? Это очень маленькая нагрузка. У меня раньше и обычные диски 100-150 iops подобного чтения держали без перегрузки. Уже частично останавливал некоторые процессы nginx / mysql, картина сильно не менялась. Все службы остановить не могу, клиенты сожрут. Запись в логи также отключал, нет эффекта.
Я уже думаю может драйвера виноваты или ещё что, с обновлением на debian 10...
Ещё вариант, atop неверно рассчитывает нагрузку на диски, хотя avio тоже велик.
fstrim - Делал, не помогло, совершенно не повлияло.
Сейчас немного продвинулся дальше и понимаю прямую зависимость % нагрузки на диск и что её вызывает. % равен примерно очереди вызовов на запись диска.
wrqm The number of write requests merged per second that were queued to the device. Также команда iostat -d -x 1 - показала мне что есть всплески записи по 15мб в сек, чего все другие включая atop не показывают. Правда что такое 15мб в сек для NVMe ... Есть над чем подумать.
[umka], Сейчас наткнулся на хороший HOWTO, раньше он мне не попадался.
Там достаточно хорошо описана безопасность в целом, и та дыра о которой я говорил разруливается за счёт превилигированных портов, тем самым ограничивая всё рутом. По умолчанию должно быть нормально. В общем нужно будет всё изучить досконально и возможно стоит вернуться к использованию NFS.
Цитирую https://www.opennet.ru/docs/HOWTO-RU/NFS-HOWTO-6.html
Спасибо за информацию.
Защита в том плане, что на машине есть другие клиенты с SSH, они хоть и не смогут без рут прав примонтировать NFS, но тем не менее наверняка есть возможность подключиться и получить данные, об этом даже попадалось несколько статей, что NFS только для работы в доверенной локальной сети. А что там с портами творится, пришлось фаервол отключать полностью...
По поводу завернуть NFS в тунель пока не очень понимаю как это делается.
lowtech, То что сказали меня не устраивает, в NFS нет паролей, вся защита базируется на IP сервера, и это абсолютно не подходит.
WebDAV меня удивил в плане скорости, даже взять решение через nginx, скорость 1гбит достигается и упираемся уже в диски. Однако есть проблема, причём эта проблема была и тогда когда тестировал NFS. Если сервер не доступен то все процессы зависают, взять тот же df -ah или dir -la, виснет на веке пока сервер не вернётся в онлайн. Ну и ещё однопоточность в webdav, да, она есть, но мне кажется это можно как то решить, буду искать... Других альтернатив пока всё равно не вижу.
PS> дело в утилите davfs2 в которой пока нет многопоточности...
В общем реализовал через WebDAV, оказалось что всё что нужно там тоже есть.
Нужно было именно с паролем, так как всё остальное не надёжно.
Возможно кому-то интересно.
При оптимизации другой таблицы, которая значительно жирнее, выяснилось что mariadb очень плохо работает с MyIsam, никакие методы оптимизации, индексы и прочее не помогали, помогла только конвертация в Innodb, которая сразу дала прирос по всем тяжёлым запросам примерно на 50-70%. Не смотря на то что разные бенчмарки (возможно старые) говорят что MyIsam на выборку значительно быстрее, однако я установил множество тормозов как только начинаем использовать сортировки, и никакие индексы тут к сожалению не помогают. Поэтому если у кого то ещё есть MyIsam, советую конвертировать в Innodb :)
Было у меня не так давно такое, в Debian пакет nginx-common сам удалился после каких то действий с apt, видимо зависимости какие то утянули его.
apt-get install nginx-common
