Что такое оптимизация 1С и как ускорить работу программы

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

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

Работы по оптимизации условно делятся на четыре уровня: прикладной код и запросы, структура метаданных и данных, настройки СУБД (MS SQL Server, PostgreSQL) и аппаратная часть. На практике до 80% проблем производительности кроется в прикладном уровне — запросах без нужных индексов, циклах с обращением к базе внутри, избыточных движениях документов. Поэтому начинать стоит именно с анализа кода и запросов, а не с покупки нового сервера.

Как понять, что системе нужна оптимизация

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

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

Диагностика: инструменты замера производительности

Основной инструмент прикладного анализа — замер производительности в конфигураторе (меню «Отладка» → «Замер производительности»). Он показывает, какие строки кода и сколько раз выполнялись, сколько времени занял каждый вызов. Замер позволяет найти «горячие точки» — те 5% кода, которые съедают 95% времени.

Для анализа запросов к СУБД используют технологический журнал платформы 1С с фильтром по событиям DBMSSQL/DBPOSTGRS и длительности, а также штатные средства самой СУБД: план выполнения запроса в SQL Server Management Studio, представления статистики в PostgreSQL. Технологический журнал требует аккуратной настройки: полный лог на рабочем сервере сам по себе создаёт ощутимую нагрузку и быстро заполняет диск.

В типовых конфигурациях на базе БСП доступна подсистема «Оценка производительности» (замеры APDEX), которая автоматически собирает время выполнения ключевых операций. Её удобно использовать для постоянного мониторинга, а не только разовой диагностики.

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

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

Вторая типичная проблема — обращение к базе внутри цикла: запрос или метод «ПолучитьОбъект()» выполняется на каждой итерации вместо одного пакетного запроса. Переписывание такого кода на один запрос с последующим обходом выборки обычно даёт ускорение в десятки раз без каких-либо изменений в инфраструктуре.

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

1. 1
   Сделайте замер производительности проблемной операции и найдите самые затратные строки кода
2. 2
   Определите, что занимает время: запрос к СУБД, циклы, вызовы серверных процедур
3. 3
   Для запроса — получите план выполнения в СУБД и проверьте использование индексов
4. 4
   Перепишите проблемный участок: добавьте отборы, уберите запросы из циклов, сократите объём выбираемых данных
5. 5
   Повторите замер на копии базы и сравните с исходным результатом
6. 6
   Только после подтверждения эффекта переносите изменение в рабочую базу

Оптимизация структуры данных и регистров

С ростом базы замедляются даже корректно написанные операции. Типовые меры на этом уровне: свёртка старых периодов по регистрам накопления и бухгалтерии, архивация неактивных данных, установка даты запрета изменения, перенос редко используемых данных в отдельные хранилища. Сокращение объёма таблиц напрямую ускоряет и запросы, и регламентное обслуживание СУБД.

Отдельная тема — итоги регистров. Хранение итогов ускоряет получение остатков и оборотов, но замедляет запись. Для регистров с интенсивной записью иногда оправдано отключение текущих итогов с периодическим пересчётом, для отчётных регистров — наоборот. Решение принимается на основе замеров конкретных операций, а не универсальных рекомендаций.

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

Настройка СУБД и сервера 1С

На уровне СУБД ключевые факторы производительности: объём выделенной памяти (SQL Server по умолчанию может забрать всю память сервера, оставив ОС и сервер 1С без ресурсов), размещение файлов данных и журналов на быстрых дисках, актуальность статистики и дефрагментация индексов, корректный уровень изоляции (для 1С на MS SQL обычно используется READ COMMITTED SNAPSHOT).

Регламентные задания СУБД — обновление статистики и реорганизация индексов — должны выполняться регулярно, но вне рабочих часов и не одновременно с обменами и резервным копированием. Пересечение тяжёлых регламентных операций — частая причина «периодических тормозов», которые сложно поймать разовым замером.

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

Сравнение вариантов

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

Даёт наибольший эффект при минимальных затратах, но требует квалификации разработчика и времени на анализ

Настройка СУБД и регламентные задания

Быстрый выигрыш при явных ошибках конфигурации, но не решает проблемы плохого прикладного кода

Усиление оборудования

Помогает при реальной нехватке ресурсов, но бессильно против неэффективных запросов — нагрузка просто съест новые мощности

Свёртка и архивация данных

Эффективна для больших старых баз, но требует тщательной подготовки и проверки остатков

Типичные ошибки при оптимизации

Отдельно стоит сказать про блокировки: значительная часть жалоб на «медленную работу» связана не со скоростью выполнения, а с ожиданием — сеансы конкурируют за одни и те же данные. Диагностируется это анализом блокировок в консоли кластера и технологическом журнале (события TLOCK, TDEADLOCK), а лечится сокращением транзакций, управляемым режимом блокировок и пересмотром порядка записи данных.

Как проверить результат оптимизации

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

Контрольные точки

Как проверить результат

Время целевой операции

Норма

Стабильно снизилось при повторных замерах

Тревожный признак

Улучшение видно только один раз или исчезает под нагрузкой

План запроса в СУБД

Норма

Поиск по индексу (Index Seek) вместо сканирования

Тревожный признак

Осталось сканирование больших таблиц

Побочные операции

Норма

Связанные отчёты и проведение работают как раньше

Тревожный признак

Ускоренная операция сломала смежный функционал

Блокировки

Норма

Сократилось время ожидания на блокировках

Тревожный признак

Появились новые взаимоблокировки

После внедрения изменений в рабочую базу понаблюдайте за системой несколько дней: часть проблем проявляется только под реальной нагрузкой или в моменты пиковой активности. Сохраните исходные замеры и описание изменений — это упростит откат и дальнейшую работу.

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

С чего начать оптимизацию, если «тормозит всё»?

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

Можно ли ускорить файловую базу 1С?

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

Поможет ли покупка SSD или увеличение памяти?

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

Как часто нужно выполнять регламентное обслуживание СУБД?

Обновление статистики обычно требуется чаще (в крупных базах — ежедневно), реорганизация индексов — реже, по мере фрагментации. Точное расписание подбирается под интенсивность записи в конкретной базе; задания планируют на нерабочие часы, не пересекая с обменами и бэкапами.

Что делать, если медленно работает только один отчёт?

Это почти всегда проблема конкретного запроса или настроек СКД. Сделайте замер производительности при формировании отчёта, найдите запрос, получите его план в СУБД. Частые причины: отсутствие отбора по периоду, обращение к виртуальным таблицам без параметров, соединение с вложенными запросами вместо временных таблиц.

Когда оптимизацию стоит поручить специалисту?

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