Перевод информационных баз 1С на твердотельные накопители (SSD) — один из наиболее частых вопросов при модернизации серверного оборудования. Разберем по шагам, дает ли установка SSD реальный выигрыш в скорости, с какими архитектурными ограничениями сталкиваются пользователи файловых баз и какие регламентные действия платформы 1С напрямую влияют на дисковую подсистему и быстродействие системы.
Какой прирост производительности дает переход на SSD
Проанализируем практический опыт эксплуатации баз 1С на SSD. В отличие от традиционных магнитных жестких дисков (HDD со скоростью 5400 или 7200 об/мин), твердотельные накопители обеспечивают многократное преимущество в операциях случайного чтения и записи (IOPS) небольшими блоками данных (4 КБ и 8 КБ), что является ключевым показателем для СУБД и файловых хранилищ 1С.
На практике перенос базы на SSD дает следующие результаты:
Формирование сложных отчетов и выборок: время построения тяжелых материальных ведомостей, книги покупок и отчетов по взаиморасчетам сокращается в 1,5–2,5 раза за счет быстрого доступа к индексам и таблицам итогов.
Регламентные операции и обслуживание: процедуры обновления конфигураций, тестирование и исправление (ТиИ), а также пакетная замена дублирующихся элементов справочников ускоряются в 2–3 раза.
Запуск и старт сеансов: время первоначального открытия программы и кэширования метаданных уменьшается в несколько раз.
Однако важно помнить: твердотельный накопитель не решает всех проблем с производительностью, если узким местом системы является сетевой канал, процессорные мощности или архитектура самой информационной базы.
Архитектурные ограничения файловых баз: почему одного SSD недостаточно
Выясним причину, по которой установка быстрого диска не всегда избавляет от зависаний в многопользовательской среде. Главным фактором здесь выступает формат хранения данных 1Cv8.1CD:
Табличные блокировки. В файловом режиме блокировка при записи накладывается на всю таблицу целиком, а не на отдельные строки (в отличие от клиент-серверного режима). Если один пользователь проводит документ «Реализация товаров и услуг», блокируется вся таблица регистра накопления «Партии товаров на складах». Остальные пользователи выстраиваются в очередь ожидания. SSD лишь сокращает время удержания блокировки за счет быстрой записи, но саму очередь при одновременной работе 10–15 человек не устраняет.
Сетевой оверхед через общий сетевой ресурс (SMB). Если база лежит в общедоступной папке сети, каждый клиентский компьютер считывает страницы базы к себе в оперативную память по сети. Тормозить будет не диск, а сетевой стек и протокол передачи файлов.
Ограничение объема таблиц. В файловой базе при стандартном размере страницы максимальный размер одной таблицы или ее индекса ограничен 4 ГБ. При приближении к этому объему производительность падает независимо от типа накопителя.
Оптимизация работы файловой базы без перехода на СУБД
Если бюджет предприятия пока не предусматривает покупку лицензий на сервер «1С:Предприятия» и СУБД (например, MS SQL Server или PostgreSQL), рассмотрим проверенные методы оптимизации файловой работы в связке с SSD.
Использование терминального доступа (RDP / RemoteApp). Перенесите базу на сервер с SSD и организуйте работу пользователей через удаленный рабочий стол. В этом случае исключается передача гигабайтов данных по локальной сети через SMB — все обращения к накопителю выполняются локально на шине сервера с максимальной скоростью SSD.
Публикация базы на веб-сервере (IIS или Apache). База данных публикуется на локальном веб-сервере. Пользователи подключаются через тонкий клиент по протоколам HTTP/HTTPS. Всю дисковую работу с файлом выполняет локально процесс веб-сервера, что предотвращает повреждение файла при сетевых сбоях на рабочих станциях.
Изменение размера страницы утилитой CNVDBFL. Для снятия ограничения в 4 ГБ на размер таблицы используем входящую в комплект поставки платформы служебную утилиту cnvdbfl.exe, позволяющую сконвертировать базу в формат с размером страницы 8, 16, 32 или 64 КБ.
Одной из наиболее распространенных причин медленной работы 1С (особенно в конфигурациях на обычных формах, таких как «Управление торговлей 10.3» или «УПП») является нерассчитанный период итогов. Разберем по шагам, как устроены итоги и почему они критичны для дисковой подсистемы.
Регистры накопления содержат две основные таблицы: таблицу движений и таблицу рассчитанных итогов (остатков на определенный срез времени). Когда в программе запрашивается остаток товара на текущую дату, платформа выполняет следующее:
Берет готовые агрегированные данные из таблицы итогов за последнюю рассчитанную точку.
Досчитывает движения только за оставшийся период между точкой итогов и целевой датой.
Если итоги не рассчитаны за несколько месяцев или лет, платформе приходится считывать с диска и перебирать в памяти абсолютно все записи регистра от начала ведения учета. Это создает колоссальную нагрузку на ввод-вывод.
Посмотрим, как выполнить расчет итогов вручную:
Откроем информационную базу в режиме «Предприятие» с правами администратора.
Перейдем в главное меню: Операции → Управление итогами.
Установим расчет итогов на конец текущего или будущего месяца (рекомендуется поддерживать актуальность итогов на 1 месяц вперед).
Нажмем кнопку Установить расчет.
Важно: процедура расчета итогов не создает новых хозяйственных операций и не изменяет существующие документы. Она формирует только внутренние служебные таблицы агрегатов, поэтому процедура абсолютно безопасна для обменов с бухгалтерскими программами (например, «1С:Бухгалтерия 3.0»).
Определение самых ресурсоемких таблиц базы данных
При поиске причин деградации скорости необходимо выяснить, какие объекты метаданных занимают наибольший объем на диске. В конфигурациях 1С имена внутренних таблиц (например, _InfoRg5782 или _AccumRgTn1234) не совпадают с названиями объектов конфигурации.
Чтобы сопоставить системные имена таблиц с реальными справочниками и регистрами, выполним программный анализ с помощью встроенной функции платформы ПолучитьСтруктуруХраненияБазыДанных:
СтруктураБазы = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрТаблица Из СтруктураБазы Цикл
Если СтрТаблица.ИмяТаблицыХранения = "_INFORG5782" Тогда
Сообщить("Имя объекта: " + СтрТаблица.Метаданные);
Сообщить("Назначение: " + СтрТаблица.Назначение);
КонецЕсли;
КонецЦикла;
Как правило, наибольший объем в базах торгового и складского учета занимают регистры накопления: «Партии товаров на складах», «Списанные товары», а также версионирование объектов и таблицы присоединенных файлов.
Критерии выбора и эксплуатации SSD под 1С
Для стабильной работы базы данных и сохранности учетной информации обратим внимание на аппаратные требования к твердотельным накопителям:
Защита от потери питания (Power Loss Protection, PLP). Это ключевое требование для серверов баз данных. Накопители корпоративного класса оснащаются аппаратными конденсаторами. Потребительский SSD при аварийном обесточивании сбрасывает буфер контроллера с ошибками, что ведет к повреждению структуры файла 1Cv8.1CD.
Отказ от RAID 5 / 6 в пользу RAID 1 / 10. Массивы с вычислением контрольных сумм (RAID 5) вызывают высокое значение задержек (write penalty) и преждевременный износ ячеек. Под базы 1С стандартом является зеркалирование (RAID 1) или массив RAID 10.
Резервирование пространства (Over-Provisioning). Никогда не заполняйте SSD более чем на 75–80%. Всегда оставляйте неразмеченную область, чтобы встроенные алгоритмы сборщика мусора (Garbage Collection) и команда TRIM могли эффективно распределять циклы стирания/записи.
Регулярное резервное копирование. Вне зависимости от ресурса накопителя (TBW) настройте автоматическую выгрузку копий информационной базы на отдельный независимый физический носитель (HDD или сетевое хранилище) по завершении каждого рабочего дня.