Каждый администратор и разработчик 1С рано или поздно сталкивается с необходимостью переноса, резервного копирования или развертывания баз данных с помощью файлов выгрузки с расширением .dt. Когда база разрастается до десятков гигабайт, этот процесс начинает занимать слишком много времени. Логичным решением кажется покупка сверхбыстрого NVMe SSD, например, популярной линейки Samsung 960/970/980/990 EVO или PRO, скорость чтения и записи которых в синтетических тестах превышает несколько гигабайт в секунду.
В этой статье мы подробно разберем, действительно ли покупка топового накопителя NVMe способна кратно ускорить развертывание баз из .dt, во что на самом деле упирается производительность платформы 1С:Предприятие при работе с файлами выгрузки и как правильно настроить дисковую подсистему сервера для достижения максимальной эффективности.
Рассмотрим стандартную ситуацию: у нас есть база данных объемом около 50 Гб. На обычном жестком диске (HDD) ноутбука процесс ее развертывания из файла .dt может занимать около двух часов. Переход на твердотельный накопитель SATA SSD (например, Samsung 850/870 EVO) сокращает это время до приемлемых 30 минут. Казалось бы, прямая зависимость налицо. Но если мы установим современный накопитель NVMe, который по паспортным данным в 5–10 раз быстрее SATA-интерфейса, мы ожидаем увидеть результат в 3–5 минут. На практике же время сокращается в лучшем случае до 10–15 минут, а иногда разница и вовсе незаметна на глаз.
Давайте выясним причину этого явления. Основная проблема кроется в том, что процесс импорта и экспорта логической структуры 1С из файла .dt чрезвычайно ресурсоемок для центрального процессора (CPU), и именно он становится «узким горлышком» всей системы.
Файл .dt — это не просто копия базы данных, а специализированный сжатый логический архив, содержащий структуру метаданных и сами данные в платформенно-независимом формате. Работа с ним кардинально отличается от работы СУБД с физическими файлами данных.
.dt может значительно превышать итоговый размер самого архива. Если диск, на котором расположена временная папка (обычно это системный диск C:), перегружен другими задачами или медленный, это еще сильнее замедлит процесс.Посмотрим на показательный пример из практики участников обсуждения. На процессоре Intel Core i7-8700K, разогнанном до частоты 4.8 ГГц, в связке с накопителем Samsung 960 PRO база данных SQL объемом 50 Гб разворачивается из файла .dt примерно за 10 минут. В то же время на стандартных частотах процессора этот процесс занимает значительно больше времени, что напрямую доказывает: тактовая частота процессора и его однопоточная производительность имеют решающее значение.
Чтобы окончательно понять разницу между дисковой и процессорной нагрузкой, проанализируем, как ведет себя система при восстановлении базы данных средствами самой СУБД (например, MS SQL Server) из родного файла резервной копии (.bak):
.bak СУБД не занимается логическим разбором и распаковкой структуры таблиц. Она выполняет последовательное бинарное копирование страниц данных напрямую в файлы базы данных (.mdf) и журнал транзакций (.ldf)..dt через конфигуратор 1С потребует десятки минут.Важный вывод: Использовать формат .dt для регулярного резервного копирования больших рабочих баз категорически не рекомендуется. Для этого должны применяться только штатные средства СУБД (MS SQL, PostgreSQL).
Начиная с версии платформы 1С:Предприятие 8.3.19, разработчики фирмы «1С» реализовали механизм многопоточной загрузки данных из файлов .dt для клиент-серверных баз данных. Теперь процесс распаковки и записи может разделяться на несколько фоновых заданий (по умолчанию их количество соответствует числу ядер процессора).
Однако на практике этот механизм имеет серьезные побочные эффекты, особенно при использовании СУБД PostgreSQL. Многопоточная запись больших объемов информации часто приводит к следующим проблемам:
lock timeout).Для обхода этих проблем и обеспечения гарантированного успешного импорта администраторы часто используют ключ принудительного запуска загрузки в один поток. Разберем пример командной строки для такого запуска:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /S"ServerName\BaseName" /N"Администратор" /P"Пароль" /RestoreIB "C:\Backup\trade.dt" -JobsCount 1
Параметр -JobsCount 1 принудительно ограничивает количество потоков импорта до одного, исключая конфликты блокировок в СУБД, хотя это и снижает потенциальную скорость загрузки на многоядерных системах.
При выборе накопителя для сервера 1С нельзя ориентироваться только на красивые цифры линейного чтения и записи (например, 3500 МБ/с для PCIe 3.0 или 7000 МБ/с для PCIe 4.0), указанные на коробках линеек Samsung 970/980/990. Реальные серверные нагрузки СУБД имеют свою специфику.
Глубина очереди запросов (Queue Depth). Большие скорости в тестах достигаются при глубокой очереди запросов (QD=32 или QD=64). Однако СУБД при записи транзакций работает преимущественно короткими блоками размером 4 Кб с глубиной очереди QD=1. В этом режиме разница между качественным SATA SSD (например, Samsung 870 PRO) и новейшим NVMe PCIe 4.0 (Samsung 990 PRO) сокращается до минимума. Они оба будут показывать схожую производительность, ограниченную латентностью контроллера и памяти.
Проблема переполнения SLC-кэша. Накопители потребительских серий (особенно линейки EVO) используют технологию динамического кэширования (Intelligent TurboWrite). Для быстрого копирования небольших объемов данных выделяется высокоскоростная область памяти, работающая в режиме SLC (однобитовая запись). Но при непрерывной записи файла базы данных размером 50–100 Гб этот кэш быстро переполняется. После этого скорость записи падает до реальной скорости физических ячеек памяти TLC/QLC — в некоторых моделях скорость падает до 500 МБ/с и ниже, что фактически сводит на нет все преимущества NVMe перед SATA.
Термотроттлинг (Thermal Throttling). Твердотельные накопители серий Samsung PRO и EVO под интенсивной нагрузкой (которой и является развертывание баз данных) выделяют огромное количество тепла. При нагреве контроллера выше 70–80 °C срабатывает защитный механизм снижения тактовой частоты контроллера, что приводит к резкому обвалу скоростей чтения и записи. Для серверных задач использование производительных накопителей NVMe без массивных радиаторов охлаждения или активного обдува недопустимо.
Износ памяти и прошивки. Базы данных постоянно перезаписывают информацию, что ведет к быстрому исчерпанию ресурса записи (TBW) накопителя. Кроме того, современные диски крайне чувствительны к качеству микропрограммы. Например, на релизе накопителей серии 980 и 990 PRO была обнаружена критическая ошибка в прошивке, из-за которой здоровье диска таяло на глазах за считанные недели. Системным администраторам критически важно регулярно проверять обновления микрокода дисков через утилиту Samsung Magician.
Чтобы сервер 1С работал на максимальной скорости, а процессы выгрузки и обслуживания баз не парализовали работу пользователей, рассмотрим проверенные практические рекомендации по настройке дисков.
Откажитесь от RAID для NVMe-накопителей. Традиционные аппаратные RAID-контроллеры не приспособлены для работы со сверхнизкими задержками современных NVMe-накопителей. Программные RAID-массивы также вносят дополнительную нагрузку на процессор для расчета контрольных сумм и синхронизации потоков. На практике один качественный производительный NVMe-накопитель без RAID показывает в тестах производительности 1С (например, в тесте Гилева) существенно лучшие результаты (минимальные задержки / latency), чем массив из нескольких таких же дисков.
Грамотно разделяйте файлы баз данных. Вместо создания одного огромного дискового пространства распределите компоненты СУБД по разным физическим накопителям:
.mdf для MS SQL). Здесь происходят операции случайного чтения и записи блоков данных..ldf в MS SQL или каталог pg_wal в PostgreSQL). Сюда СУБД записывает данные строго последовательно. Разделение файлов данных и журнала транзакций на разные физические устройства значительно снижает нагрузку на головки чтения/записи (в случае HDD) и уменьшает конфликты контроллеров (в случае SSD).TempDB. Платформа 1С генерирует колоссальное количество временных таблиц при сложных запросах и проведении документов. Скорость работы TempDB напрямую определяет общую отзывчивость всей системы.Избегайте использования RAMDisk. Попытка разместить файлы базы данных или системную базу TempDB на виртуальном диске, созданном в оперативной памяти (RAMDisk), часто не дает ожидаемого прироста производительности. Программная прослойка эмуляции диска создает избыточную нагрузку на ядра процессора, переключая контексты выполнения. В результате производительность СУБД может оказаться даже ниже, чем при работе с современным физическим NVMe-накопителем, подключенным напрямую по шине PCIe.
Проанализировав все факторы, мы видим, что покупка накопителей уровня Samsung 960/970/980 PRO оправдана для серверов баз данных СУБД, но сама по себе она не решит проблему долгого развертывания файлов .dt. Для ускорения этих процессов в первую очередь выбирайте процессоры с максимально высокой частотой на одно ядро.