Дисковая подсистема под 1С и SQL: почему NVMe не всегда спасает

Замена дисков — самое понятное решение для медленной базы и самое неточное. Иногда оно даёт кратный выигрыш, иногда — ничего, притом что счёт в обоих случаях одинаковый. Разберём, какие характеристики дисков действительно важны учётной системе, как замерить своё состояние до покупки и почему сервер на NVMe может работать медленнее сервера на обычных SSD.

Маркетинговые характеристики накопителей построены вокруг двух чисел: пропускная способность в мегабайтах в секунду и количество операций в секунду. Для учётной системы важно третье — задержка отдельной операции.

Причина в характере нагрузки. Проведение документа — это не чтение гигабайта, а несколько десятков мелких обращений, каждое из которых должно завершиться, прежде чем начнётся следующее. Общая длительность складывается из задержек, а не делится на пропускную способность.

Аналогия: если вам надо доставить сто писем по разным адресам, вместимость грузовика не поможет — важна скорость каждой поездки.

Целевые значения для боевой базы 1С, которых мы придерживаемся:

Журнал транзакций требует самой низкой задержки, потому что коммит транзакции не завершается, пока запись в журнал не подтверждена. Каждая проведённая накладная упирается в эту задержку напрямую.

До любых решений о покупке — замер. Два источника данных.

Внутренняя статистика SQL Server по файлам. Показывает фактические задержки на реальной нагрузке:

SELECT DB_NAME(vfs.database_id) AS db, mf.name AS file_name, mf.physical_name,
       vfs.num_of_reads, vfs.io_stall_read_ms / NULLIF(vfs.num_of_reads,0) AS r_ms,
       vfs.num_of_writes, vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes,0) AS w_ms,
       CAST(vfs.size_on_disk_bytes / 1048576.0 AS DECIMAL(12,0)) AS size_mb
FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs
JOIN sys.master_files mf ON mf.database_id = vfs.database_id AND mf.file_id = vfs.file_id
ORDER BY r_ms DESC;

Статистика накапливается с момента старта службы, так что смотреть её надо на сервере, проработавшем хотя бы несколько дней.

Синтетический тест утилитой diskspd от Microsoft. Нужен, когда надо оценить потенциал диска отдельно от текущей нагрузки — например, перед миграцией.

diskspd.exe -b8K -r -o4 -t8 -w30 -d60 -Sh -L -c10G T:\test.dat

Параметры подобраны под профиль учётной базы: блок 8 КБ (размер страницы SQL Server), случайный доступ, 30 % записи, 8 потоков, обход кэша ОС, вывод статистики задержек.

Для теста журнала профиль другой — последовательная запись мелкими блоками:

diskspd.exe -b60K -si -o1 -t1 -w100 -d60 -Sh -L -c5G L:\test.dat

Смотреть надо не среднее, а перцентили в выводе. Средняя задержка 3 мс при 99-м перцентиле в 200 мс означает, что каждая сотая операция подвисает — и пользователи это чувствуют.

Три типа файлов с разным характером обращений. На одном томе они конкурируют.

Файл данных. Случайное чтение блоками по 8 и 64 КБ, запись пачками при сбросе контрольной точки.

Журнал транзакций. Строго последовательная запись мелкими порциями, чтение почти отсутствует.

tempdb. Интенсивная запись и чтение, много создания и удаления объектов.

Проблема совмещения: последовательная запись журнала перестаёт быть последовательной, если между её порциями головка или очередь занята случайными обращениями к данным. На SSD эффект слабее, чем на дисках, но не исчезает — очередь контроллера общая.

Приоритет разнесения, если томов ограниченное число:

1. Журнал транзакций отдельно от всего. Самый важный шаг.
2. tempdb отдельно.
3. Бэкапы отдельно — и обязательно не на том же массиве, что база.
4. Файлы данных.

Третий пункт — не про производительность, а про выживание: бэкапы на том же массиве, что и база, теряются вместе с ней при отказе контроллера.

Про несколько файлов данных для пользовательской базы: в отличие от tempdb, разбивать боевую базу 1С на несколько файлов обычно не нужно. Contention на служебных страницах для неё не характерен, а управление становится сложнее.

Уровень массива влияет на задержку записи сильнее, чем принято думать.

Причина слабости RAID 5 и 6 на записи — штраф на вычисление чётности. Чтобы изменить один блок, контроллеру нужно прочитать старый блок, прочитать чётность, вычислить новую и записать оба. Одна логическая операция записи превращается в четыре физические, для RAID 6 — в шесть.

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

Частая находка при аудите: сервер с быстрыми дисками, собранными в RAID 5 «ради объёма», и жалобы на медленное проведение документов. Пересборка в RAID 10 при том же железе даёт кратное улучшение записи ценой половины ёмкости.

Отдельно про RAID 0 под tempdb. Технически оправдано: данные не нужно сохранять. Практически — отказ любого диска остановит инстанс целиком, и на боевом сервере мы так не делаем. Разумный компромисс — RAID 1 из двух NVMe.

Аппаратный RAID-контроллер имеет собственную память под кэш, и её настройка часто решает больше, чем выбор накопителей.

Ключевой параметр — политика записи. Write-back означает, что контроллер подтверждает запись сразу после попадания данных в свой кэш, не дожидаясь физической записи на диск. Write-through — подтверждает только после реальной записи.

Разница в задержке записи — на порядок. Для журнала транзакций это критично.

Условие безопасности write-back: рабочая батарея или суперконденсатор на контроллере. Без них при пропадании питания содержимое кэша теряется, а SQL Server считает эти транзакции подтверждёнными — прямой путь к повреждению базы.

И вот здесь кроется самая частая находка при разборе «внезапно стало медленно на старом сервере»: батарея контроллера деградировала, контроллер автоматически переключился в write-through, и задержка записи выросла в десять раз. Никаких сообщений на уровне ОС при этом нет.

# HPE
ssacli ctrl slot=0 show detail | findstr /i "Cache Battery"
# Dell
racadm storage get controllers -o | findstr /i "Cache"

Проверка состояния батареи контроллера должна быть в мониторинге на любом сервере с аппаратным RAID. Это дешёвая проба, ловящая дорогую проблему.

Второй параметр — соотношение кэша чтения и записи. Для SQL Server имеет смысл смещать в сторону записи: чтение и так кэшируется буферным пулом СУБД, а вот запись выигрывает.

Ситуации, в которых замена дисков на самые быстрые не даёт ничего. Все — из практики.

Узкое место в другом месте. Если задержки по dm_io_virtual_file_stats и так в пределах 5 мс, а база тормозит — дело не в дисках. Замена ускорит то, что и так быстро.

Нехватка памяти. При достаточном объёме памяти рабочий набор базы помещается в буферный пул, и диск читается редко. Добавить памяти часто дешевле и эффективнее, чем ускорить диски.

Виртуализация с ограничением IOPS. На платформах виртуализации бывают лимиты на уровне политики хранения. Быстрый массив под гипервизором при лимите в 2000 IOPS на диск отдаёт 2000 IOPS.

Тонкие диски с отложенным выделением. Первая запись в новый блок thin-диска требует его выделения, что добавляет задержку. На активно растущей базе это заметно.

Конкуренция на хосте. Соседняя виртуальная машина, льющая бэкап, отбирает всю производительность массива. Диски при этом любые.

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

Общий вывод, который мы формулируем клиентам так: диски стоит менять, когда замер показал, что они узкое место. Во всех остальных случаях это ставка, и она чаще проигрывает, чем выигрывает.

Порядок правильный такой: замерить задержки по файлам, убедиться, что они выше целевых, проверить очевидное (батарея контроллера, уровень RAID, разнос файлов, лимиты гипервизора), и только потом рассматривать покупку.

Компания-производитель мебели, 33 рабочих места, УТ на MS SQL. Меняли сервер: старый — 2015 года на SAS-дисках, новый — свежий Dell с четырьмя NVMe.

После переезда пользователи сказали, что стало хуже. Не «так же», а именно хуже.

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

Замеры показали, что дело не в психологии. Проведение реализации: 3,1 секунды на старом сервере, 5,7 на новом. Формирование ОСВ: 41 секунда против 68.

Статистика по файлам дала первую зацепку. Задержка записи в журнал транзакций — 14 мс. На NVMe. Это ненормально примерно на порядок.

Дальше разбирались с конфигурацией хранилища и нашли три вещи, наложившиеся друг на друга.

Первое: четыре NVMe были собраны в RAID 5. Логика была понятной — «максимум полезного объёма из дорогих дисков». Штраф на запись в RAID 5 никто не учёл.

Второе: все файлы — данные, журнал, tempdb и каталог бэкапов — лежали на одном логическом томе. На старом сервере они были разнесены по трём разным массивам.

Третье, и самое обидное: виртуальный диск был создан как thin с политикой хранения, в которой стоял лимит 5000 IOPS. Лимит поставили при создании шаблона ВМ год назад, чтобы тестовые машины не мешали друг другу, и он приехал в новую боевую ВМ вместе с шаблоном.

То есть старый сервер с обычными SAS-дисками выдавал больше операций, чем новый на NVMe, просто потому что ему никто ничего не ограничивал.

Что сделали за одно вечернее окно: пересобрали массив в RAID 10, создали три отдельных тома под данные, журнал и tempdb, сняли лимит IOPS в политике хранения, перенесли каталог бэкапов на отдельное хранилище.

Итог: задержка записи в журнал упала с 14 мс до 0,4 мс. Проведение реализации — 0,9 секунды, то есть втрое быстрее старого сервера и вшестеро быстрее того, что было после переезда. ОСВ — 12 секунд.

Железо всё это время было одним и тем же. Разница целиком в том, как оно было сконфигурировано.

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

Что важнее для базы 1С — IOPS или задержка?

Задержка. Учётная нагрузка состоит из множества мелких последовательных обращений, каждое из которых ждёт завершения предыдущего. Целевые значения: до 10 мс на файле данных и до 5 мс на журнале транзакций.

Подходит ли RAID 5 для базы 1С?

Для файлов данных и особенно журнала — нет. Штраф на вычисление чётности превращает одну логическую запись в четыре физических операции, из-за чего задержка записи растёт кратно. RAID 5 уместен под бэкапы и архивы, база должна жить на RAID 10.

Почему сервер внезапно стал медленным без изменений?

Частая причина на серверах с аппаратным RAID — деградация батареи контроллера. Контроллер автоматически переключается из write-back в write-through, задержка записи вырастает в разы, и никаких сообщений на уровне операционной системы при этом нет.

Даст ли переход на NVMe ускорение работы 1С?

Только если замер показал, что диски действительно узкое место. Если задержки по файлам уже в пределах 5 мс, ускорять нечего — ищите причину в памяти, статистике, блокировках или настройках СУБД.