Как оптимизировать работу в 1С: пошаговое руководство

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

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

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

Как найти узкое место: диагностика перед оптимизацией

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

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

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

Оптимизация сервера и СУБД

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

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

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

Настройка регламентных и фоновых заданий

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

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

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

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

Работа с данными: итоги, регистры и объём базы

Большой объём данных — естественная причина замедления. Проверьте, какие таблицы занимают больше всего места. Часто лидируют регистры сведений с историей (курсы, цены, версии объектов) и регистры накопления за много лет.

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

Для старых данных рассмотрите свёртку базы или перенос архивных периодов в отдельную базу. Это трудоёмкая операция, требующая тестирования, но для баз, работающих много лет, она даёт самый заметный эффект. Удаление помеченных объектов выполняйте регулярно, а не раз в год — накопленные «мёртвые» ссылки усложняют контроль целостности.

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

Если тормозит конкретная операция, причина почти всегда в запросе или алгоритме. Типовые проблемы: запросы без отборов, читающие всю таблицу; обращения к данным внутри цикла; соединения с виртуальными таблицами без условий; использование «СКД-отчёта на весь период» без ограничений.

Основной инструмент анализа — замер производительности в конфигураторе (Отладка → Замер производительности). Он покажет, какие строки кода и запросы занимают больше всего времени. Для запросов дополнительно смотрите план выполнения на стороне СУБД: сканирование таблицы вместо поиска по индексу — явный признак проблемы.

Типовые приёмы ускорения: переносить выборку данных из цикла в один запрос с пакетом, использовать временные таблицы с индексами, накладывать отборы до соединения таблиц, а не после. Изменения кода тестируйте на копии базы с реальным объёмом данных — на пустой тестовой базе проблемный запрос может работать быстро и создать ложное ощущение решения.

Ускорение на стороне пользователя

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

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

Проверьте сетевое подключение: работа по Wi-Fi вместо кабеля, перегруженный VPN-канал или сетевой диск для файловой базы с высокой задержкой способны «съесть» всю производительность, которую дала оптимизация сервера.

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

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

Время проведения типового документа

Норма

Сократилось относительно замера до оптимизации и стабильно в течение дня

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

Время не изменилось или скачет в зависимости от часа

Формирование ключевого отчёта

Норма

Отчёт строится за приемлемое время без таймаутов

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

Отчёт падает по таймауту или грузит сервер на 100%

Жалобы пользователей

Норма

Количество обращений о тормозах снизилось

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

Тормоза перешли на другое время суток — проверьте расписание заданий

Загрузка сервера в часы пик

Норма

Процессор и диски имеют запас, нет очередей к диску

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

Дисковая очередь растёт, память исчерпана — узкое место не устранено

Когда оптимизации недостаточно

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

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

Частые вопросы

С чего начать, если 1С тормозит, но причина непонятна?

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

Поможет ли переход с файловой базы на SQL?

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

Как часто нужно делать реиндексацию и обновление статистики?

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

Можно ли ускорить 1С без доработки конфигурации?

Часто да. Настройка СУБД, исключения в антивирусе, разнесение регламентных заданий, пересчёт итогов, замена толстого клиента на тонкий и обновление платформы не требуют изменения кода и дают заметный эффект. Доработка нужна, когда проблема в самих запросах и алгоритмах конфигурации.

Опасно ли отключать регламентные задания в типовой конфигурации?

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

Как понять, что пора сворачивать базу?

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