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

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

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

Все действия, описанные ниже, выполняйте только после создания резервной копии. Для файловых баз достаточно копии файла 1Cv8.1CD, для клиент-серверных — штатной выгрузки в dt либо бэкапа средствами СУБД. Часть операций (реиндексация, очистка данных) требует монопольного доступа и выполняется в нерабочее время.

Шаг 1. Определите, где именно тормозит система

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

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

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

Шаг 2. Настройте СУБД и сервер 1С

Если база работает на MS SQL Server, проверьте ключевые параметры: ограничение памяти (max server memory) должно оставлять ресурс операционной системе, модель восстановления для рабочих баз обычно «Простая» при настроенных бэкапах, автоувеличение файлов базы — фиксированным шагом, а не процентом. Убедитесь, что tempdb размещена на быстром диске и имеет достаточный размер.

Для PostgreSQL, применяемого с 1С, важны параметры shared_buffers, work_mem и effective_cache_size — их подбирают под объём памяти сервера. Используйте сборку PostgreSQL, рекомендованную для работы с 1С, поскольку в ней учтены особенности платформы.

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

Шаг 3. Обновите статистику и перестройте индексы

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

Дополнительно выполните тестирование и исправление информационной базы через конфигуратор (Администрирование → Тестирование и исправление) с включённой реиндексацией таблиц. Для больших баз эта операция занимает часы и требует монопольного доступа — планируйте её на ночь или выходные.

1. 1
   Сделайте резервную копию базы
2. 2
   Настройте в СУБД регулярное обновление статистики (например, еженощно)
3. 3
   Настройте реорганизацию или перестроение индексов по расписанию
4. 4
   Запустите тестирование и исправление с реиндексацией в нерабочее время
5. 5
   Замерьте время типовых операций и сравните с исходными значениями

Шаг 4. Сократите объём данных

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

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

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

Шаг 5. Разберитесь с регламентными заданиями и фоновыми процессами

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

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

Шаг 6. Оптимизируйте запросы и код конфигурации

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

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

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

Шаг 7. Контролируйте результат и поддерживайте систему

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

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

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

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

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

Норма

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

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

Не изменилось или выросло

План проблемного запроса

Норма

Используется поиск по индексу

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

Полное сканирование большой таблицы

Размер самых больших таблиц

Норма

Стабилен или уменьшился после очистки

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

Продолжает быстро расти

Регламентные задания

Норма

Выполняются в нерабочее время без ошибок

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

Запускаются днём, зависают или завершаются с ошибками

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

Можно ли оптимизировать файловую базу 1С или нужно переходить на клиент-сервер?

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

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

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

Поможет ли увеличение оперативной памяти сервера?

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

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

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

Опасно ли сокращать журнал регистрации?

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