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

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

Методы оптимизации различаются для файловых и клиент-серверных баз. Файловый вариант ограничен по своей архитектуре и плохо масштабируется при одновременной работе более 5–10 пользователей, поэтому для больших баз главный шаг оптимизации — переход на клиент-серверный режим с MS SQL Server, PostgreSQL или другой поддерживаемой СУБД. Клиент-серверная база даёт доступ к полноценным инструментам: планам запросов, индексам, статистике и регламентным заданиям обслуживания.

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

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

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

Основной инструмент диагностики на стороне платформы — технологический журнал (ТЖ). Он включается через файл logcfg.xml в каталоге conf сервера 1С и позволяет фиксировать длительные вызовы СУБД, запросы, блокировки и взаимоблокировки. Для анализа одной операции достаточно включить сбор событий DBMSSQL (или DBPOSTGRS/DBORACLE) с порогом длительности и воспроизвести проблемное действие.

Параллельно используйте штатные средства СУБД: в MS SQL Server — Activity Monitor, представления sys.dm_exec_requests и sys.dm_tran_locks, построитель планов запросов; в PostgreSQL — pg_stat_activity и pg_stat_statements. Дополнительно в самой 1С полезны замеры производительности (отладка — замер производительности), которые показывают, какие строки кода и запросы занимают основное время.

Обслуживание СУБД: статистика, индексы, модель восстановления

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

Для MS SQL Server проверьте модель восстановления базы. Полная модель (Full) без регулярного резервного копирования журнала транзакций приводит к неконтролируемому росту файла .ldf, который может занять десятки и сотни гигабайт и замедлить работу. Если вам не требуется восстановление на произвольный момент времени, переведите базу в простую модель (Simple). Если требуется — настройте регулярный backup журнала транзакций.

Также проверьте параметры tempdb (для MS SQL рекомендуется несколько файлов данных по числу ядер, но не более разумного предела), отключите автосжатие базы (autoshrink) — оно вызывает фрагментацию, и убедитесь, что файлы данных и журнала располагаются на быстрых дисках, желательно SSD. Антивирус на сервере должен исключать каталоги файлов СУБД и каталог сервера 1С из проверки в реальном времени.

Сокращение объёма данных: свёртка, удаление, архивирование

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

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

Кроме свёртки, регулярно удаляйте помеченные объекты (Операции — Удаление помеченных объектов), очищайте журналы регистрации за старые периоды (старые срезы можно выгрузить в архив через ВыгрузитьЖурналРегистрации), удаляйте ненужные версии объектов, если включено версионирование, и следите за таблицами очередей обменов данными — в базах с активными синхронизациями они растут особенно быстро.

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

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

Если конфигурация дорабатывалась, значительная часть проблем производительности обычно находится в прикладном коде. Типовые антипаттерны: запросы в цикле (вместо одного запроса с соединением), обращение к данным через точку от ссылки в цикле (так называемые неявные запросы), выборка всех полей вместо нужных, использование ПОЛНОГО соединения больших таблиц, отсутствие отборов по индексированным полям и получение данных функциями в условиях компоновки.

Проверяйте план выполнения проблемных запросов на стороне СУБД: сканирование таблицы (table scan / clustered index scan) на больших таблицах там, где ожидается поиск по индексу (index seek), — прямой сигнал к доработке запроса или добавлению индекса. В 1С дополнительные индексы можно создавать только через свойство «Индексировать» у реквизитов объектов метаданных — ручное создание индексов средствами СУБД не поддерживается и может привести к ошибкам при обновлении конфигурации.

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

Настройки платформы и сервера 1С

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

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

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

Сравнение вариантов развёртывания

Файловая база

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

Клиент-сервер (MS SQL / PostgreSQL)

Подходит для средних и больших баз с десятками пользователей. Требует администрирования СУБД, но даёт индексы, планы запросов и параллелизм

1С:Фреш / облачный вариант

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

Контроль результата и регулярный мониторинг

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

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

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

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

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

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

Норма

Сократилось или стабильно в пределах нормы для вашей базы

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

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

Длительные запросы в мониторинге СУБД

Норма

Их число и длительность снижаются

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

Появляются новые тяжёлые запросы

Блокировки и взаимоблокировки

Норма

Единичные, короткие, без влияния на пользователей

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

Массовые ожидания, ошибки превышения времени ожидания

Размер базы и темп роста

Норма

Рост замедлился после чистки и свёртки

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

База растёт прежними темпами — значит, источник роста не найден

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

Как понять, что базе нужен переход с файлового режима на клиент-серверный?

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

Можно ли создавать индексы напрямую средствами SQL Server?

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

Как часто нужно делать свёртку базы?

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

Почему база тормозит именно в конце месяца или квартала?

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

Влияет ли антивирус на скорость работы 1С?

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

Что делать, если после всех мер база всё равно медленная?

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