Как оптимизировать 1С и ускорить работу системы

Медленная 1С редко тормозит «сама по себе»: почти всегда за просадкой производительности стоит конкретная причина — перегруженный сервер СУБД, неоптимальные запросы в конфигурации, разросшиеся таблицы итогов или конкуренция фоновых заданий за ресурсы. Оптимизация начинается не с покупки железа, а с диагностики: нужно понять, где именно теряется время — на клиенте, на сервере приложений или в базе данных.

Практика показывает, что наибольший эффект дают три направления: настройка СУБД (MS SQL, PostgreSQL), пересмотр регламентных заданий и оптимизация кода проблемных операций. Апгрейд оборудования оправдан только после того, как устранены программные узкие места, иначе вы просто купите более дорогой способ тормозить.

Ниже — прикладной порядок действий: от замера текущей скорости до проверки результата, с границами того, что можно безопасно сделать своими силами, а где лучше привлечь специалиста.

С чего начать: замеры и поиск узкого места

Без исходных замеров оптимизация превращается в гадание. Зафиксируйте время выполнения 3–5 самых болезненных операций: проведение крупного документа, формирование ключевого отчёта, закрытие месяца. Замеры делайте в типичное рабочее время и повторяйте несколько раз, чтобы исключить случайные всплески.

Для поиска причины используйте встроенные инструменты. Технологический журнал кластера 1С позволяет собрать длительные вызовы и запросы к СУБД по событию DBMSSQL или DBPOSTGRS с порогом длительности. В конфигураторе доступен «Замер производительности» (Отладка → Замер производительности), который покажет, какие строки кода занимают больше всего времени.

Параллельно посмотрите на сервер СУБД: загрузку дисковой подсистемы, память, ожидания блокировок. Если запрос в 1С занимает 30 секунд, а на SQL-сервере видны длительные ожидания диска — проблема инфраструктурная. Если запрос сам по себе тяжёлый и сканирует миллионы строк — проблема в коде или индексах.

Настройка СУБД: где 1С теряет больше всего времени

Большинство просадок производительности клиент-серверной 1С находится на уровне СУБД. Для MS SQL проверьте базовые вещи: достаточно ли памяти выделено серверу (ограничьте max server memory, оставив запас ОС), лежат ли данные и журнал транзакций на разных дисках, не работает ли антивирус с проверкой файлов базы в реальном времени — каталоги СУБД нужно добавить в исключения.

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

Для PostgreSQL аналогично важны регулярный VACUUM ANALYZE, корректные настройки памяти (shared_buffers, work_mem) и использование сборки, адаптированной под 1С. Не копируйте чужие конфигурационные файлы без понимания: параметры подбираются под объём базы и ресурсы конкретного сервера.

Обслуживание базы: итоги, версии и журналы

Разросшиеся таблицы — частая причина деградации. Проверьте, какие таблицы занимают больше всего места (в MS SQL это видно через отчёт по использованию диска, в PostgreSQL — через запрос к pg_relation_size). Типичные «тяжеловесы»: регистры накопления и сведений с многолетней историей, таблицы версий объектов, журналы регистрации.

Полезные шаги: свёртка старых периодов по регистрам, если методисты подтвердили, что история не нужна в оперативной работе; отключение версионирования там, где оно не используется; настройка срока хранения журнала регистрации. В файловых базах регулярно выполняйте «Тестирование и исправление» с реиндексацией и сжатием — но только на копии и при отсутствии активных пользователей.

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

Регламентные и фоновые задания: убираем конкуренцию

Фоновые задания невидимы для пользователей, но именно они часто «съедают» сервер в рабочие часы. Откройте консоль заданий и составьте список всего, что выполняется: обмены, синхронизации, расчёты, загрузка курсов, полнотекстовое индексирование, обновление агрегатов.

Действия по разгрузке: отключите задания, которые никто не использует (частое наследие внедрений); перенесите тяжёлые операции на ночь или на время минимальной нагрузки; разведите по времени задания, которые сейчас стартуют одновременно и блокируют друг друга; для обменов настройте расписание с разумной периодичностью вместо непрерывного цикла.

1. 1
   Выгрузите список всех регламентных заданий с расписаниями и временем последнего выполнения
2. 2
   Отметьте неиспользуемые задания и отключите их, зафиксировав изменение
3. 3
   Перенесите тяжёлые задания (обмены, индексирование) на нерабочие часы
4. 4
   Разведите одновременно стартующие задания с интервалом 10–15 минут
5. 5
   Через неделю проверьте журнал: нет ли ошибок и пропущенных выполнений

Оптимизация кода и запросов

Если замер показал, что время уходит на конкретный запрос или алгоритм, дальше работа идёт в конфигураторе. Классические проблемы: запросы в цикле, обращение к данным через точку от ссылки («разворачивание» ссылок), выборка лишних полей, отсутствие индексов под условия отбора, соединения с виртуальными таблицами без отборов.

Типовые приёмы: вынести запрос из цикла и получить данные одним пакетом; заменить обращения через точку на соединение с таблицей справочника; накладывать отборы на виртуальные таблицы через параметры, а не в секции ГДЕ; проверить план запроса в СУБД и при необходимости добавить индекс по полям отбора. Для тяжёлых расчётов рассмотрите перенос в фоновое выполнение, чтобы не блокировать пользователя.

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

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

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

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

Апгрейд оборудования оправдан, когда программные причины устранены, а ресурсов объективно не хватает. Приоритеты для сервера 1С и СУБД: быстрые диски (SSD/NVMe для базы и журнала транзакций дают самый заметный эффект), достаточный объём оперативной памяти, современный процессор с высокой частотой ядра — многие операции 1С однопоточны, и частота важнее числа ядер.

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

Проверка результата и типичные ошибки

После каждого изменения повторите исходные замеры в сопоставимых условиях. Ускорение должно быть измеримым: например, отчёт формировался 90 секунд, стал 20. Если изменений нет — откатывайте и ищите дальше, не накапливайте «оптимизации» без эффекта.

Частые вопросы об оптимизации 1С