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

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

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

Сначала измеряем: ищем узкое место, а не угадываем

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

Базовые инструменты диагностики:

• 📊 Замер производительности в Конфигураторе: меню Отладка → Замер производительности. Запустите замер, повторите медленное действие, остановите — платформа покажет строки кода и их долю во времени выполнения.
• 📈 APDEX — интегральная оценка отклика по ключевым операциям. Целевое время задаёте сами; итоговый балл от 0 до 1, где значения ближе к 0,9–0,95 считаются хорошими. Собирается конфигурацией «Оценка производительности» (входит в типовые как подсистема).
• 🧰 Технологический журнал (ТЖ) — настраивается файлом logcfg.xml в каталоге conf платформы. По событиям DBMSSQL, TLOCK, TDEADLOCK, TTIMEOUT видно долгие обращения к СУБД и блокировки.

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

Чтобы не собирать картину по кусочкам, в корпоративной среде ставят «Центр управления производительностью» (ЦУП) из состава корпоративного инструментального пакета (КИП) — он сводит APDEX, ТЖ и данные СУБД в одну картину и показывает проблемные операции на графиках. Для небольшой базы хватает встроенного замера и короткого ТЖ, для нагруженной сотнями пользователей — полноценного мониторинга.

Медленные запросы и индексы: где прячутся секунды

Самая частая причина тормозов в больших базах — тяжёлые запросы, которые читают лишнее и не попадают в индекс.

Что искать по ТЖ и средствами СУБД:

1. Запросы с большим числом прочитанных строк и логических чтений — их видно по событию DBMSSQL в ТЖ и по статистике MS SQL.
2. Запросы с соединениями (ЛЕВОЕ СОЕДИНЕНИЕ) по неиндексированным полям и с условиями по вычисляемым выражениям.
3. Обращения к виртуальным таблицам регистров без отбора — читается весь регистр.

Что помогает:

• ✅ Накладывайте отбор внутри виртуальной таблицы (в её параметрах), а не после выборки всех данных.
• ✅ Избегайте соединений с вложенными запросами и соединений «таблица с собой» в горячих отчётах.
• ✅ Не используйте ВЫБРАТЬ * в прикладном коде — берите только нужные поля, иначе платформа тянет все реквизиты.
• ✅ Проверяйте индексирование реквизитов, по которым идёт частый отбор: в конфигураторе у реквизита справочника/регистра есть свойство Индексировать.

На стороне MS SQL узкие места в плане запроса видны через SQL Server Management Studio: включите фактический план выполнения и ищите сканирование таблиц (Table Scan, Index Scan) там, где ожидался поиск по индексу. Для 1С полезно выставить на экземпляре SQL Server max degree of parallelism = 1 — это штатная рекомендация для баз 1С, она убирает лишний параллелизм на коротких запросах.

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

В клиент-серверном варианте половина производительности зависит от того, как настроен кластер. Процессы кластера — это ragent (агент), rmngr (менеджер) и rphost (рабочий процесс), в котором и живут сеансы.

Ключевые настройки в консоли кластера (оснастка администрирования серверов 1С):

• 🧩 Несколько рабочих процессов. По умолчанию один rphost на всех. На многопользовательской базе включите несколько процессов — нагрузка и память распределятся, а падение одного процесса не уронит весь кластер. Параметр — на уровне рабочего сервера.
• 🧮 Лимиты памяти рабочего процесса. Задайте «Максимальный объём памяти рабочих процессов» и порог перезапуска по превышению — утёкшая память будет вычищаться автоматически, без ручного рестарта.
• 🗂 Требования назначения функциональности — если серверов в кластере несколько, разнесите по ним фоновые задания, сеансы и сервисы, чтобы регламентные операции не мешали интерактивной работе.

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

• 🔒 Переведите конфигурацию на управляемый режим управления блокировкой данных, если она ещё на автоматическом. Управляемые блокировки точнее по объёму и реже приводят к эскалации до уровня таблицы.
• ⏱ Укоротите длинные транзакции: не держите открытую запись, пока пользователь что-то вводит; тяжёлые обработки проводите пакетами, а не одной транзакцией на всю базу.
• 🔁 Разбирайте взаимоблокировки (TDEADLOCK в ТЖ) по порядку захвата ресурсов — чаще всего два процесса берут одни и те же объекты в разной последовательности.

Администрировать кластер из скриптов удобно через сервер администрирования ras и консоль rac. Безопасные для начала команды:

rac cluster list
rac session list --cluster=<id>
rac session list --cluster=<id> --licenses

Если точного синтаксиса подкоманды не помните — не угадывайте параметры, а посмотрите rac help и rac <объект> help.

Регламентное обслуживание СУБД и журнала регистрации

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

Что настроить на стороне MS SQL (через план обслуживания или задание):

• 🔧 Обновление статистики — чтобы оптимизатор строил адекватные планы. Для активных баз 1С — ежедневно или чаще.
• 🧱 Дефрагментация индексов — ALTER INDEX ... REORGANIZE при умеренной фрагментации и REBUILD при сильной. Обычно ночью, по расписанию.
• 💾 Резервное копирование и контроль размера журнала транзакций. При модели восстановления FULL регулярно делайте бэкап лога, иначе файл лога разрастётся и забьёт диск.

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

Настройка в режиме 1С:Предприятие: раздел Администрирование → Настройки журнала регистрации (в типовых конфигурациях на «Такси»). Там задайте:

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

С версий платформы 8.3.5 журнал по умолчанию в формате SQLite (1Cv8.lgd). Если он уже разросся, сокращение делается штатно — через настройки журнала с указанием даты, до которой удалить записи .

Удобный порядок регламента — в чек-листе ниже.

Ускоряем клиентскую часть и интерфейс

Иногда «1С тормозит» — это не сервер, а клиент: раздутый кэш, тяжёлые формы, медленная сеть до пользователя.

Что помогает на рабочих местах:

• 🧹 Очистка кэша клиента. Накопленный кэш метаданных иногда вызывает подтормаживания и странности интерфейса. Запуск через ярлык с ключом /ClearCache сбрасывает его; кэш лежит в профиле пользователя (каталог 1cv82/1cv8 в %LOCALAPPDATA%). Перед удалением каталога вручную закройте все окна 1С этого пользователя.
• 🖥 Тонкий клиент вместо толстого в клиент-серверной работе — по сети передаются только данные формы, а не вся выборка. Для удалённых пользователей это заметно быстрее.
• 📝 Лёгкие формы списков. Уберите из горячих списков лишние колонки и условное оформление по сложным условиям — отрисовка каждой строки стоит времени.
• 🔎 Отборы вместо «показать всё». Приучите пользователей открывать журналы документов с отбором по организации/периоду, а не листать весь список за годы.

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

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

Железо и инфраструктура под 1С

Когда код и настройки вычищены, дальше упираются в оборудование. 1С чувствительна к конкретным ресурсам, и дорогой «многоядерный» сервер без быстрого диска не поможет.

Что важно по приоритету:

Практические ориентиры по инфраструктуре:

• 🧱 Разносите роли. Сервер 1С и сервер СУБД — разные службы с разным профилем нагрузки. На серьёзной базе их держат на отдельных машинах (или как минимум не конкурируют за одно «железо»).
• 💽 tempdb на быстрый диск. В MS SQL системная база tempdb — узкое место при тяжёлых запросах 1С; выносите её на самый быстрый носитель.
• 🧮 Память рабочим процессам. Платформа 1С x64 снимает ограничение адресуемой памяти — используйте 64-разрядный сервер и давайте процессам достаточно RAM, иначе пойдут выгрузки и перезапуски.

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