Сервер 1С тормозит: как найти узкое место и устранить его

Чтобы ускорить сервер 1С, сначала найдите узкое место, а потом меняйте настройки. Обычно тормоза дают одна-две причины: диск под базой данных, нехватка памяти у СУБД, устаревшая статистика, ожидания на блокировках или тяжёлый запрос в конкретном отчёте.

Бессистемная «оптимизация всего» обычно ничего не даёт. Рабочий порядок такой: замер, железо, кластер, СУБД, запросы, регламент. Всё относится к клиент-серверному варианту 1С:Предприятия 8.3 на Windows Server или Linux.

Диагностика: где именно теряется время

Жалоба «1С тормозит» ничего не говорит. Сначала уточните три вещи:

• 🕐 Когда — весь день, по утрам, в конце месяца, после обновления.
• 👥 У кого — у всех или у одного пользователя, в одной базе или во всех.
• 📄 Где — при открытии программы, при проведении конкретного документа, в одном отчёте.

Если медленно у одного человека — смотрите его компьютер и сеть. Если у всех и везде — сервер. Если в одном документе или отчёте — код и запросы.

Счётчики производительности Windows

Запустите perfmon на сервере 1С и на сервере СУБД, соберите данные за рабочий день. Главные счётчики:

На Linux те же вещи смотрят через top, vmstat и iostat -x.

Технологический журнал

Технологический журнал (ТЖ) — главный инструмент. Он включается файлом logcfg.xml в каталоге conf платформы, например C:\Program Files\1cv8\conf\logcfg.xml. Пример: долгие запросы к СУБД и события блокировок.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="duration" value="3000000"/>
    </event>
    <event>
      <eq property="name" value="DBPOSTGRS"/>
      <gt property="duration" value="3000000"/>
    </event>
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <event><eq property="name" value="EXCP"/></event>
    <property name="all"/>
  </log>
</config>

На платформе 8.3 duration задаётся в микросекундах, поэтому 3000000 — это 3 секунды. history — сколько часов хранить журнал.

Что искать в результатах:

• 🐢 DBMSSQL / DBPOSTGRS — самые долгие и самые частые запросы. Поле Context покажет модуль и строку кода.
• 🔒 TLOCK, TTIMEOUT, TDEADLOCK — ожидания на управляемых блокировках, таймауты и взаимоблокировки.
• 💥 EXCP — падения рабочих процессов и ошибки, которые пользователи не видят.

Оценка с точки зрения пользователя

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

Железо сервера 1С и СУБД: что ускоряет работу сильнее всего

Платформа выполняет каждый серверный вызов в одном потоке. Поэтому для 1С частота ядра важнее числа ядер: 8 ядер на 3,5 ГГц обычно дают пользователю больше, чем 32 ядра на 2,1 ГГц.

Ориентиры для одной типовой конфигурации (БП, ЗУП, УТ) при одновременной работе пользователей:

Цифры ориентировочные: на них сильно влияют размер базы, доработки и интенсивность обменов.

Приёмы, которые дают прирост без покупки железа

1. Схема электропитания. В Windows Server по умолчанию стоит «Сбалансированная». Переключите на «Высокая производительность»: powercfg /setactive SCHEME_MIN. Заодно проверьте в BIOS/UEFI, что профиль питания тоже производительный. На серверах с агрессивным энергосбережением прирост на коротких вызовах бывает заметным.
2. Исключения антивируса. Добавьте в исключения каталог данных кластера (по умолчанию C:\Program Files\1cv8\srvinfo), файлы баз СУБД (.mdf, .ldf, каталог данных PostgreSQL), каталог ТЖ и временные каталоги. Проверка каждого чтения антивирусом съедает диск.
3. Сеть между 1С и СУБД. Если серверы разные — минимум 1 Гбит/с с малой задержкой, без лишних маршрутизаторов между ними. Если на одном хосте с MS SQL — включите протокол Shared Memory.
4. Виртуализация. Не переподписывайте процессоры хоста и не включайте динамическую память для виртуальной машины СУБД: 1С плохо переносит «плавающие» ресурсы.

Настройка кластера серверов 1С для ускорения

Кластер настраивается в консоли администрирования серверов 1С. Параметры находятся в двух местах, и их часто путают.

Свойства рабочего сервера

Открываются через Кластеры → <кластер> → Рабочие серверы → <сервер> → Свойства.

• ⚙️ Количество ИБ на процесс — сколько баз обслуживает один рабочий процесс. Для крупной базы ставят 1: тогда тяжёлая база не делит процесс и память с соседями.
• ⚙️ Количество соединений на процесс — при достижении предела кластер запускает новый rphost. Значение по умолчанию подходит для большинства случаев; уменьшают его, когда один процесс разрастается по памяти.
• 🧠 Временно допустимый объём памяти процессов и интервал его превышения — защищают сервер от процесса, который «распух».
• 🧠 Критический объём памяти процессов — после него кластер обрывает самые тяжёлые вызовы, чтобы сервер не ушёл в своп.
• 🔌 Диапазон IP-портов рабочих процессов тоже задаётся здесь.

Блокировки и свойства информационной базы

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

Очистка сеансовых данных

Если за месяцы работы кластер стал медленно открывать базы, а каталог srvinfo\reg_1541 занимает гигабайты, помогает очистка кеша сеансовых данных. Остановите службу «Агент сервера 1С:Предприятия 8.3», удалите каталоги snccntx* внутри reg_1541 и запустите службу снова.

Оптимизация СУБД: память, tempdb, статистика и индексы

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

Microsoft SQL Server

1. Max server memory. Без ограничения SQL Server забирает почти всю память и вытесняет рабочие процессы 1С. На общем сервере оставьте ОС 4–6 ГБ, процессам 1С — по их фактическому потреблению, остальное отдайте SQL.
2. MAXDOP = 1. Для 1С обычно отключают параллелизм запросов: параллельные планы на OLTP-нагрузке чаще мешают, чем помогают.
3. tempdb. Вынесите на отдельный быстрый диск и создайте несколько файлов одинакового размера (обычно по числу ядер, но не больше 8).
4. Модель восстановления. Полная модель без регулярного резервного копирования журнала раздувает файл .ldf. Либо настройте копирование журнала, либо переведите базу в простую модель, если допустима потеря данных с момента последней полной копии.
5. Мгновенная инициализация файлов (право Perform Volume Maintenance Tasks для учётной записи службы SQL) ускоряет рост файлов данных.

EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 49152; RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1; RECONFIGURE;

Здесь 49152 МБ — пример для сервера на 64 ГБ, где SQL работает вместе с 1С. Пересчитайте под свой объём.

PostgreSQL

Используйте сборку PostgreSQL с патчами для 1С (дистрибутив от фирмы 1С или Postgres Pro). Обычный PostgreSQL из репозитория без патчей с типовыми конфигурациями работает хуже или не работает вовсе.

Отправные точки для postgresql.conf на выделенном сервере СУБД:

После изменения shared_buffers нужен перезапуск службы PostgreSQL, а значит, остановка работы пользователей.

Статистика и индексы

Устаревшая статистика — частая причина внезапных тормозов: СУБД строит план под старое распределение данных и выбирает перебор вместо индекса.

• 📊 Обновление статистики — ежедневно ночью. В MS SQL — задача Update Statistics в плане обслуживания или sp_updatestats. В PostgreSQL — VACUUM ANALYZE или автоочистка с нормальными порогами.
• 🧹 Очистка процедурного кеша после обновления статистики в MS SQL (DBCC FREEPROCCACHE), чтобы запросы перестроили планы.
• 🗂️ Индексы. При фрагментации 5–30% — реорганизация, выше 30% — перестроение. Перестроение нагружает диск и журнал, поэтому — раз в неделю ночью.

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

Когда железо и СУБД в порядке, а конкретный отчёт или документ всё равно долгий, причина в коде.

Как найти виновника

1. В Конфигураторе включите Отладка → Замер производительности, выполните медленную операцию в режиме отладки, остановите замер. Вы увидите строки кода, на которые ушло больше всего времени.
2. Для запроса из ТЖ возьмите текст (поле Sql) и план выполнения. Чтобы ТЖ писал планы, добавьте в logcfg.xml элемент <plansql/>, но включайте его ненадолго: он сам нагружает сервер.

Типовые ошибки в запросах 1С

• 🔁 Запрос в цикле. Тысяча запросов по одной строке медленнее одного запроса на тысячу строк. Соберите ключи в таблицу значений и передайте одним параметром.
• 🎯 Отбор виртуальной таблицы через ГДЕ. Условие для Остатки и ОстаткиИОбороты пишите в параметрах виртуальной таблицы, а не в секции ГДЕ — иначе платформа сначала посчитает остатки по всем аналитикам.
• 🔗 Соединение с подзапросом. СУБД плохо оценивает подзапросы. Положите результат во временную таблицу и проиндексируйте её по полю соединения.
• ➕ ИЛИ в условии. Часто ломает использование индекса. Иногда быстрее разбить на два запроса через ОБЪЕДИНИТЬ ВСЕ.
• 🧩 Разыменование через точку. Обращение Документ.Контрагент.ОсновнойДоговор.Валюта порождает неявные соединения. Берите только нужные поля.

// Медленно: остатки по всем складам, отбор потом
ВЫБРАТЬ Остатки.Номенклатура, Остатки.КоличествоОстаток
ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки КАК Остатки
ГДЕ Остатки.Склад = &Склад

// Быстро: отбор в параметрах виртуальной таблицы
ВЫБРАТЬ Остатки.Номенклатура, Остатки.КоличествоОстаток
ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки(, Склад = &Склад) КАК Остатки

Имя регистра в примере условное — подставьте регистр своей конфигурации.

Регулярное обслуживание, без которого сервер снова замедлится

Разовая настройка теряет эффект за несколько месяцев. Ускорение держится только на регламенте.

Регламентные задания внутри базы

В БП, ЗУП и УТ список открывается через Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания. Проверьте:

• ⏰ тяжёлые задания (обмены, загрузка курсов, полнотекстовое индексирование, удаление помеченных) не запускаются в часы пик;
• 🔍 полнотекстовый поиск обновляется по расписанию ночью, а если им не пользуются — индекс можно не вести вовсе;
• 🧾 нет заданий, которые падают с ошибкой и перезапускаются каждую минуту.

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

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