Почему сильно тормозит файловая база 1С при проведении документов и как это исправить?

Рано или поздно многие системные администраторы и разработчики сталкиваются с ситуацией, когда файловая база данных 1С (особенно на базе конфигураций «Управление производственным предприятием» или «Управление торговым предприятием») начинает критически зависать при проведении документов. Ситуация выглядит парадоксально: в базе работает всего один пользователь, объем базы относительно небольшой (до 3 ГБ), сервер оснащен мощным процессором Intel i7 и достаточным объемом оперативной памяти, а диспетчер задач показывает околонулевую нагрузку на процессор, диск и память. При этом проведение простейшего документа с 5–10 позициями товаров может занимать от 3 до 5 минут.

В этой статье мы подробно разберем, почему возникает эта проблема, проведем глубокую диагностику узких мест и рассмотрим пошаговые методы оптимизации как на уровне СУБД и операционной системы, так и на уровне логики самой конфигурации 1С.

Шаг 1. Анализируем показатели производительности и ищем «невидимую» нагрузку

Когда стандартный диспетчер задач Windows показывает низкую нагрузку, это часто вводит в заблуждение. Выясним причину этого феномена. Дело в том, что процесс проведения документа в 1С выполняется строго в один поток. Это значит, что вся вычислительная нагрузка ложится ровно на одно ядро процессора. Если на вашем сервере установлен многоядерный процессор (например, 8 ядер), то 100% загрузка одного ядра в общем графике диспетчера задач отобразится как скромные 12.5% общей нагрузки на CPU. При этом ядро, выполняющее проведение, будет работать на пределе своих возможностей.

Вторая скрытая проблема — дисковые операции. Файловая СУБД 1С при проведении документов совершает огромное количество мелких операций чтения и записи. Стандартные утилиты мониторинга могут показывать низкую скорость передачи данных (в МБ/с), но при этом диск будет перегружен количеством запросов. Нам необходимо запустить «Монитор ресурсов» Windows и обратить внимание на показатель «Длина очереди к диску» (Disk Queue Length). Если это значение в момент проведения документа превышает 1.5–2, дисковая подсистема не справляется с потоком мелких транзакций.

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

ОбщийМодуль.УправлениеЗапасамиПартионныйУчет.Модуль

Если этот модуль по замеру съедает более 70–80% времени проведения, проблема носит комплексный характер: программа застревает на обработке огромного количества записей в таблицах партий, совершая миллионы мелких дисковых операций записи во временные таблицы.

Шаг 2. Устраняем аппаратные и системные узкие места

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

1. Программный RAID-массив — главный враг файловой 1С. Зеркалирование дисков (RAID 1), организованное средствами операционной системы Windows, создает колоссальные задержки при записи данных. Поскольку файловая 1С постоянно блокирует и перезаписывает файл 1Cv8.1CD малыми порциями, программный RAID вынужден непрерывно синхронизировать блоки на двух физических накопителях. Это нивелирует все преимущества даже быстрых SSD-дисков. Рекомендуется отказаться от программного RAID в пользу качественного аппаратного RAID-контроллера с кэшем записи или использовать один быстрый SSD под базу данных, настроив ежечасное резервное копирование на соседний физический диск.
2. Режим электропитания операционной системы. По умолчанию в Windows Server часто включена сбалансированная схема питания. При работе с файловой 1С процессор постоянно переключается между ожиданием дискового ввода-вывода и расчетами. В сбалансированном режиме ОС снижает тактовую частоту процессора во время пауз, а когда 1С возобновляет расчеты, процессор не успевает мгновенно поднять частоту до максимума. Обязательно установите схему электропитания «Высокая производительность» (High Performance) в панели управления сервером. Это заставит процессор всегда работать на максимальной базовой частоте.
3. Исключения антивирусного ПО и Windows Defender. Защитник Windows может сканировать каждый временный файл, создаваемый платформой 1С при формировании запросов. Добавьте в список исключений антивируса:
   • Расширения файлов *.1CD, *.1CL, *.cdn.
   • Каталог установки платформы 1С (обычно C:\Program Files\1cv8 или C:\Program Files (x86)\1cv8).
   • Временные папки пользователей RDP (переменные среды %TEMP% и %TMP%).
4. Локальные пути доступа в терминальной сессии (RDP). Если пользователи работают на сервере через удаленный рабочий стол (RDP), путь к информационной базе в окне запуска 1С обязательно должен быть локальным (например, C:\1C_Bases\UTP\), а не сетевым (например, \\ServerName\1C_Bases\UTP\). Использование UNC-путей внутри терминальной сессии задействует сетевые протоколы SMB, что увеличивает время отклика СУБД в десятки раз.

Шаг 3. Оптимизируем настройки партионного учета в 1С

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

Вариант А. Отключение оперативного проведения партий. Это самый быстрый и безболезненный способ ускорить проведение документов «здесь и сейчас». Выполним следующие действия:

1. Перейдем в настройки параметров учета (раздел «Настройки параметров учета» -> вкладка «Режимы учета» или «Партионный учет» в зависимости от редакции конфигурации).
2. Снимем флаг «Списывать партии при проведении документов».
3. Сохраним настройки.

После этого документы (включая возвраты и реализации) начнут проводиться практически мгновенно, так как система перестанет рассчитывать себестоимость «на лету». Все движения по партиям и расчет себестоимости списания переносятся на нерабочее время. Для этого ночью по расписанию (через регламентные задания или вручную) запускается обработка «Проведение по партиям» за прошедший день.

Вариант Б. Переход на РАУЗ (Расширенная аналитика учета затрат). Если специфика вашего бизнеса требует видеть себестоимость сразу, классический партионный учет в крупных файловых базах становится нежизнеспособным. В конфигурациях УПП и УТП реализован альтернативный механизм — РАУЗ.

РАУЗ отказывается от концепции партий и последовательностей документов при оперативном проведении. Документы проводятся мгновенно, делая записи только в количественном выражении. Полный расчет стоимости запасов и затрат производится один раз в конце месяца регламентным документом «Расчет себестоимости», который решает сложную систему линейных уравнений. Переход на РАУЗ кардинально решает проблему производительности файловых баз.

Шаг 4. Физическая дефрагментация структуры базы данных (.1CD)

Даже если размер базы составляет менее 3 ГБ, внутренняя структура файла базы данных может быть сильно фрагментирована. Обычное «Тестирование и исправление» (ТиИ) через Конфигуратор или запуск утилиты chdbfl.exe исправляют только логические ошибки и индексы, но они не умеют физически перестраивать структуру хранения таблиц внутри файла. Со временем в файле базы накапливается «мусор» (удаленные объекты, которые физически остаются в файле).

Выполним процедуру полной физической дефрагментации структуры СУБД 1С по шагам:

1. Запустим Конфигуратор информационной базы.
2. Выберем меню Администрирование -> Выгрузить информационную базу... и сохраним базу в резервный файл с расширением .dt.
3. Создадим на быстром диске (желательно SSD) абсолютно новую, пустую папку.
4. Создадим в списке запуска 1С новую пустую информационную базу, указав путь к созданной папке.
5. Откроем эту новую базу в режиме Конфигуратора.
6. Выберем меню Администрирование -> Загрузить информационную базу... и укажем ранее выгруженный файл .dt.

Этот процесс полностью пересоздает структуру файла базы данных 1Cv8.1CD с нуля. Все таблицы записываются последовательно, удаляются фантомные записи, перестраиваются индексы, а размер файла на диске часто уменьшается на 20–40%. Это дает существенный прирост к скорости файловых операций чтения/записи.

Шаг 5. Радикальный шаг — перенос временных файлов на RAM-диск

Если конфигурационные изменения по каким-то причинам невозможны, а дисковая система все еще остается «узким горлышком», мы можем перенаправить временные файлы СУБД 1С в оперативную память. Во время проведения документов 1С активно использует временные таблицы, которые физически создаются в системной папке TEMP пользователя Windows.

Проанализируем этот метод. Мы можем выделить небольшой объем оперативной памяти (например, 1–2 ГБ) под виртуальный диск (RAM-диск) с помощью бесплатного стороннего софта. После этого перенаправим переменные окружения TEMP и TMP для пользователей RDP на этот виртуальный скоростной диск. Запись временных таблиц в оперативную память происходит со скоростью работы ОЗУ, что полностью убирает задержки дисковой очереди.

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

ПутьКВременнымФайлам = КаталогВременныхФайлов();
Сообщить("Временные файлы сессии 1С записываются в: " + ПутьКВременнымФайлам);

Если этот путь указывает на созданный нами RAM-диск, скорость работы тяжелых запросов в партионном учете возрастет в разы.

Резюмируя все вышесказанное: для решения проблемы зависаний файловой базы 1С:УТП при проведении документов необходимо действовать комплексно. Отключите программное зеркалирование дисков, настройте схему питания сервера на максимальную производительность, выполните выгрузку/загрузку базы через .dt для дефрагментации структуры и рассмотрите возможность отключения оперативного списания партий или перехода на РАУЗ.