Как ускорить работу базы 1С 8.3: методы оптимизации

Начните не с «волшебной» настройки, а с замера: откройте Конфигуратор → Администрирование → Тестирование и исправление, а в клиент-серверной базе — журнал запросов СУБД. Тормоза в 1С почти всегда сводятся к четырём причинам: распухшая база без регламентного обслуживания, неудачные запросы в конфигурации, слабо настроенная СУБД и нехватка памяти на рабочих процессах сервера.

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

Сначала измеряем: где именно теряется время

Пока вы не знаете, что тормозит, любая «оптимизация» — это гадание. Соберите факты.

• 🔍 Замер производительности в Конфигураторе. Запустите базу в режиме отладки, включите Отладка → Замер производительности, выполните «тормозящую» операцию, остановите замер. Увидите, какая строка кода и сколько раз выполнялась — часто это запрос в цикле.
• 📊 APDEX. Встроенная оценка отклика ключевых операций (норматив — время, за которое операция считается быстрой). Настраивается в разделе Администрирование конфигураций на БСП, в подсистеме оценки производительности.
• 🧩 Центр управления производительностью (ЦУП) и технологический журнал — для клиент-серверных баз. ЦУП собирает статистику по запросам и блокировкам, техжурнал (logcfg.xml) пишет длительные вызовы и ошибки СУБД.
• 📈 Журнал запросов самой СУБД. В MS SQL — через Extended Events или Profiler, в PostgreSQL — через log_min_duration_statement. Так видно реальные тяжёлые запросы.

Запишите базовые цифры до изменений: время открытия типовой формы, время проведения документа, время формирования отчёта. Без них вы не поймёте, помогла правка или нет.

Регламентное обслуживание средствами платформы

Это первое, что даёт эффект без денег и без переписывания кода. Делать — в нерабочее время.

Откройте Конфигуратор → Администрирование → Тестирование и исправление и включайте проверки по ситуации:

1. Реиндексация таблиц — перестраивает индексы, убирает деградацию после массовых изменений.
2. Проверка логической и ссылочной целостности — находит «битые» ссылки и документы без нужных данных.
3. Пересчёт итогов — актуализирует итоги регистров; заметно ускоряет отчёты по остаткам.
4. Сжатие таблиц информационной базы — физически удаляет место, освобождённое помеченными на удаление объектами.
5. Реструктуризация таблиц — приводит структуру хранения к текущей конфигурации.

Отдельно почистите то, что растёт само:

• 🗂️ Журнал регистрации. В разделе Администрирование → Настройка журнала регистрации сократите срок хранения и разбейте по периодам. Разбухший журнал тормозит и запись событий, и его просмотр.
• 🧹 Кэш клиента. При странном поведении форм помогает очистка каталога кэша пользователя — папка вида %LOCALAPPDATA%\1C\1cv8\<идентификатор базы>. Перед удалением закройте все сеансы этого пользователя. Кэш пересоздастся при следующем запуске.
• ⚙️ Устаревшие остатки регистров. В типовых конфигурациях есть регламентное задание пересчёта и установки периода рассчитанных итогов — проверьте, что оно включено.

Что ускоряет файловую базу

Файловый вариант (один файл 1Cv8.1CD) удобен для 1–3 пользователей, но у него жёсткие пределы.

• 📦 Размер. В файловом варианте есть ограничение на объём одной таблицы (порядка нескольких гигабайт). Когда база подбирается к пределу, тормоза и сбои почти гарантированы — это сигнал к переходу на клиент-серверный вариант, а не к тонкой настройке.
• 💽 Диск и сеть. Файловую базу держите на локальном SSD, а не на сетевой папке. Работа по сети (особенно по Wi-Fi) — главная причина «тормозит всё» в файловом варианте. Если доступ нужен нескольким людям, правильнее опубликовать базу через веб-сервер, а не раздавать файл по сети.
• 🧪 Проверка физической целостности. Для файловой базы есть утилита chdbfl.exe в каталоге bin платформы. Она находит и (с галочкой «Исправлять») чинит физические повреждения файла. Запускать — на копии и при закрытой базе.
• 🔁 Регулярный dt и обратная загрузка. Выгрузка в .dt и загрузка обратно пересобирает файл, убирает фрагментацию и часто уменьшает размер. Это ручной аналог «дефрагментации» для файлового варианта.

Настройка СУБД в клиент-серверном варианте

Здесь живёт основной резерв скорости. Платформа 1С работает с MS SQL Server и PostgreSQL; принципы близки.

Общие для любой СУБД:

• Регулярно обновляйте статистику и перестраивайте/реорганизуйте индексы. Устаревшая статистика — причина того, что СУБД выбирает плохой план запроса.
• Выделите СУБД достаточно оперативной памяти, но не всю — оставьте ОС и, если сервер 1С на той же машине, рабочим процессам.
• Не держите базу данных на одном шпинделе с файлом подкачки и журналами. Разнесите данные, лог транзакций и tempdb по разным дискам, по возможности NVMe.

MS SQL Server:

PostgreSQL:

• Ставьте сборку PostgreSQL, адаптированную для 1С (обычная ванильная сборка хуже работает с типовыми запросами платформы).
• Настройте память: shared_buffers, work_mem, effective_cache_size, maintenance_work_mem под объём ОЗУ сервера.
• Включите и настройте autovacuum — без регулярного вакуума таблицы распухают и запросы деградируют.

Не забывайте про журнал транзакций. В MS SQL при модели Full лог без регулярного бэкапа растёт до размеров, превышающих саму базу, и в какой-то момент диск заканчивается — база встаёт. Либо делайте бэкап лога по расписанию, либо переходите на Simple, если восстановление на точку во времени не требуется. В PostgreSQL за это отвечают WAL и настройки контрольных точек.

Регламентные операции СУБД (обновление статистики, перестроение индексов, очистка процедурного кэша) ставьте на расписание в ночное окно — вручную их делать забывают, а именно их отсутствие постепенно «съедает» скорость.

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

Даже идеальная СУБД не спасёт от тяжёлого кода. Что проверить в конфигурации:

• 🔁 Запросы в цикле. Классическая ошибка — обращение к базе внутри цикла по строкам. Выносите выборку в один пакетный запрос до цикла.
• 🧱 Соединения с виртуальными таблицами. Не соединяйте большие таблицы с виртуальными (Остатки, ОстаткиИОбороты) без отбора — отбор нужно передавать в параметры виртуальной таблицы, а не фильтровать результат.
• 🗃️ Временные таблицы и индексы. Промежуточные результаты складывайте во временные таблицы и индексируйте поля соединений и условий.
• 🔐 RLS (ограничение доступа на уровне записей). Мощный, но дорогой механизм: каждая такая проверка утяжеляет запросы. Проверьте, всем ли ролям он реально нужен.
• 📑 Индексирование реквизитов. Для реквизитов, по которым часто идёт отбор, включите индексирование в конфигураторе («Индексировать» или «Индексировать с доп. упорядочиванием»).

Отдельная тема — блокировки. Когда документы проводятся одновременно, а записи пересекаются, пользователи ждут друг друга. Что помогает:

• 🔒 Проверьте режим управления блокировками. Управляемые блокировки блокируют только нужные данные, а не целые таблицы, и почти всегда работают быстрее автоматических. Типовые конфигурации давно на управляемом режиме — важно не сломать это доработками.
• ⏱️ Длинные транзакции держат блокировки дольше. Не открывайте транзакцию, внутри которой идёт долгий расчёт или обращение к внешнему сервису: сначала соберите данные, потом коротко запишите.
• 🔁 Взаимоблокировки (deadlock) видны в техжурнале и логе СУБД. Повторяющийся deadlock на одной и той же паре объектов — сигнал пересмотреть порядок записи в коде.

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

Настройка кластера серверов 1С

В клиент-серверном варианте за производительность отвечает не только СУБД, но и кластер: агент сервера ragent, менеджер rmngr и рабочие процессы rphost, которые и обслуживают соединения.

Управлять кластером можно из консоли администрирования или командами rac через сервер администрирования ras.

Ключевые настройки кластера (в консоли — свойства кластера):

• 🧮 Количество рабочих процессов. Один rphost не должен тащить всех. Задайте «Количество информационных баз на процесс» и «Количество соединений на процесс», чтобы система поднимала несколько rphost и распределяла нагрузку.
• 🧠 Память и перезапуск. Параметры «Допустимый объём памяти» и «Интервал перезапуска» заставляют кластер мягко перезапускать растущий rphost, не копя утечки. Без этого процесс пухнет, и база «встаёт».
• ⚖️ Уровень отказоустойчивости и профили. На нагруженных базах разносите рабочие процессы и при необходимости добавляйте рабочие серверы в кластер.

Посмотреть состояние можно так:

rac cluster list
rac session list --cluster=<uuid>

Если после всех настроек один сервер упирается в потолок по CPU или памяти — это уже вопрос железа: либо вертикальный рост (ядра, ОЗУ, NVMe), либо горизонтальный (ещё один рабочий сервер в кластере).

Чего настройками не исправить

Честно о пределах, чтобы не тратить время впустую.

• 🧱 Антивирус на лету. Если антивирус проверяет файл базы или каталоги кластера при каждом обращении, падение скорости может быть кратным. Добавьте файлы и процессы 1С в исключения — это часто даёт больший эффект, чем тонкая настройка СУБД.
• 🌐 Тонкий клиент по медленному каналу. По узкому или нестабильному интернету тонкий клиент будет «подтормаживать» независимо от сервера. Здесь помогает веб-клиент или терминальный доступ, а не оптимизация базы.
• 📦 Данные, которые не нужны. Если в базе лежат десятки гигабайт документов за давно закрытые периоды, их имеет смысл свернуть (операция «Свертка информационной базы») после закрытия и сверки, а не разгонять запросы по всему архиву.
• 🖥️ Слабое железо. HDD вместо SSD, нехватка ОЗУ, одно ядро на СУБД и сервер 1С сразу — настройками это не компенсируется. Сначала адекватное железо, потом оптимизация.

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