Как не дать базе 1С «лечь» во время пиковых нагрузок: 3 базовых шага

Глубокое погружение: 3 столпа высокой производительности 1С:Предприятие

1. Регулярное обслуживание индексов СУБД (MS SQL / PostgreSQL)

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

Когда индекс фрагментирован, СУБД вынуждена совершать значительно больше операций ввода-вывода (I/O) для считывания нужных строк. Считывать данные «кусками», разбросанными по всему диску, всегда дольше, чем читать последовательный блок.

[Фрагментированный индекс] -> СУБД читает 10 разных страниц диска -> Медленно
[Дефрагментированный индекс] -> СУБД читает 1 сплошной блок -> Быстро

Как с этим бороться?

В зависимости от используемой СУБД применяются разностные подходы к регламентным работам:

Для Microsoft SQL Server:

• Дефрагментация (Reorganize): Выполняется прямо во время работы пользователей, если фрагментация составляет от 10% до 30%. Процесс устраняет разрывы на уровне страниц без блокировки таблиц.

• Перестроение (Rebuild): Полный перерасчет и пересоздание индекса с нуля. Применяется при фрагментации свыше 30%. Требует значительных ресурсов и может блокировать таблицы (в версиях Standard), поэтому процедуру планируют на ночное время или выходные дни.

• Обновление статистики (Update Statistics): Оптимизатор MS SQL строит план выполнения запроса на основе статистики распределения данных. Если статистика устарела, СУБД может выбрать абсолютно неоптимальный путь выполнении запроса (например, вместо поиска по индексу начнет перебирать всю таблицу Index Scan). Регламентное обновление статистики с параметром FULLSCAN — обязательный шаг.

Для PostgreSQL:

• Autovacuum / VACUUM FULL: PostgreSQL использует механизм MVCC (многоверсионность строк). При изменении или удалении записи старая версия физически остается в базе и маркируется как «мертвая». Если Autovacuum не успевает чистить «мертвые» строки, база раздувается (происходит так называемый bloat). Periodic VACUUM ANALYZE критически важен для очистки пространства и обновления статистики оптимизатора.

• REINDEX: Позволяет перестроить индексы, устранив их вздутие. В современных версиях PostgreSQL доступна команда REINDEX DATABASE CONCURRENTLY, позволяющая перестроить индексы без жесткой блокировки таблиц на запись.

Вывод: Обслуживание индексов и сбор статистики необходимо автоматизировать через службы обслуживания (Maintenance Plans в MS SQL или pg_cron / скрипты в Linux для Postgres) и запускать строго по графику.

2. Локальный кэш и временные файлы: гигиена рабочих мест

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

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

К чему приводит «битый» кэш?

• Нетипичные ошибки формата Ошибка формата потока, Отображение формы не соответствует структуре.

• Неверное отображение элементов интерфейса (пропавшие кнопки, сдвинутые колонки).

• «Зависание» платформы при открытии конкретных справочников или документов.

Механика очистки кэша

Кэш клиента 1С хранится в профиле пользователя ОС Windows по путям:

• %userprofile%\AppData\Local\1C\1Cv8 (временные файлы, файлы скомпилированных форм)

• %userprofile%\AppData\Roaming\1C\1Cv8 (настройки пользователей, пользовательские кеши)

Методы решения проблемы:

1. Ручная или автоматизированная очистка: Удаление каталогов с буквенно-цифровыми GUID-именами в папках Local и Roaming (скриптами PowerShell или .bat).

2. Параметр /ClearCache: Добавление ключа запуска в свойствах базы в окне запуска 1С. Этот ключ заставляет платформу сбросить кэш вызовов серверных процедур при старте текущей сессии.

3. Передобавление базы: Удаление базы из списка запуска и добавление ее заново создаст для нее новый каталог кэша с уникальным GUID.

Важно: Сервер приложений 1С (кластер) также имеет свой кэш (snaccxt, callcntr и т.д.). При фундаментальных обновлениях системы перезапуск службы 1C:Enterprise Server Daemon/Service с очисткой серверного кэша иногда является единственным способом применить изменения коректно.

3. Оптимизация тяжелых запросов и виртуальных таблиц

Даже самое мощное железо и идеально настроенный SQL-сервер не спасут систему, если код на языке 1С написан с нарушениями стандартов разработки. Основной источник «тяжелых» отчетов и длительных проведений документов — неоптимальные запросы.

Разберем наиболее частые архитектурные ошибки:

А. Запросы внутри циклов (Запрос в цикле)

Худшая практика в разработке на 1С. Когда разработчик выбирает выборку из 1000 элементов и внутри цикла Для Каждого выполняет отдельный запрос к базе данных, происходит 1000 сетевых обращений к СУБД.

• Проблема: Высокие накладные расходы на сетевой обмен и компиляцию запросов СУБД.

• Решение: Выборка всех необходимых данных одним единым запросом до начала цикла с соединением по массиву или сгружением во временную таблицу, с последующей обработкой в памяти.

Фрагмент кода

// d60; НЕПРАВИЛЬНО (Запрос в цикле)
Для Каждого СтрокаТЧ Из СсылкаНаДокумент.Товары Цикл
    Запрос = Новый Запрос;
    Запрос.Текст = "ВЫБРАТЬ Цена ИЗ РегионЦен ГДЕ Номенклатура = &Номенклатура";
    Запрос.УстановитьПараметр("Номенклатура", СтрокаТЧ.Номенклатура);
    // Выполнение запроса...
КонецЦикла;

// c89; ПРАВИЛЬНО (Один запрос на весь массив)
МассивНоменклатуры = СсылкаНаДокумент.Товары.ВыгрузитьКолонку("Номенклатура");
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Номенклатура, Цена ИЗ РегионЦен ГДЕ Номенклатура В (&МассивНоменклатуры)";
Запрос.УстановитьПараметр("МассивНоменклатуры", МассивНоменклатуры);
// Результат обрабатывается в памяти

Б. Неиспользование параметров в виртуальных таблицах

Виртуальные таблицы регистров (например, РегистрыНакопления.Остатки, РегистрыСведений.СрезПоследних) — это уникальный и мощный инструмент 1С. Однако логика их работы требует дисциплины.

• Ошибка: Наложение условий на виртуальную таблицу через секцию ГДЕ.

  Фрагмент кода

  // d60; Фильтрация происходит ПОСЛЕ расчета остатков по всей базе
  ВЫБРАТЬ Номенклатура, КоличествоОстаток 
  ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки() 
  ГДЕ Номенклатура = &НашаНоменклатура
  

• Правильный подход: Передача условий напрямую в параметры виртуальной таблицы.

  Фрагмент кода

  // c89; СУБД сразу рассчитывает остаток только для указанного элемента
  ВЫБРАТЬ Номенклатура, КоличествоОстаток 
  ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки(, Номенклатура = &НашаНоменклатура)
  

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

В. Отсутствие индексации во временных таблицах

При построении сложных отчетов (например, на базе СКД) данные часто помещаются во временные таблицы. Если к временной таблице далее происходит левое или внутреннее соединение, отсутствие индекса по полю связи приводит к так называемому Nested Loops (вложенным циклам на уровне СУБД) с полной чисткой и сканированием данных.

• Решение: Явное индексирование временных таблиц по ключевым полям связи (ключ соединения: Номенклатура, Контрагент, Договор и т.д.) с помощью инструкции ИНДЕКСИРОВАТЬ ПО.

Резюме

Оптимизация 1С — это всегда комплексный подход. Нельзя решить проблему производительности, занимаясь только кодом или только сервером:

1. СУБД нуждается в чистоте и актуальной карте данных (индексы и статистика).

2. Клиентская часть требует технической гигиены (очистка кэша от устаревших структур).

3. Код 1С должен писаться с пониманием того, во что именно платформа транслирует его на языке SQL.