Почему тормозит 1С: причины медленной работы и что делать по шагам

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

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

Сначала уточните симптом

Фраза «1С тормозит» может означать очень разные проблемы. До любых действий я задаю несколько вопросов:

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

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

Почему тормозит 1С в файловом режиме

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

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

Почему тормозит 1С на сервере

В клиент-серверном режиме вариантов больше, и они сложнее.

Настройки сервера и СУБД

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

Отдельная история — размещение. Сервер приложений и СУБД можно разнести по разным машинам, а при росте нагрузки — построить кластер 1С. Но масштабирование оправдано, когда ресурсы действительно исчерпаны, а не когда сервер ждёт блокировок.

Блокировки

Если пользователи жалуются, что «проведение висит», а потом падает ошибка о превышении времени ожидания или взаимоблокировке — это блокировки. Типовые причины:

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

Решения — перевод на управляемые блокировки, сокращение времени транзакций, перенос тяжёлых операций за пределы транзакции и в фоновые задания, разнесение регламентных операций по времени.

Код, доработки и настройки базы

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

Ещё две настройки, которые часто влияют на скорость:

• Версионирование объектов. Если хранить историю изменений всех документов подряд, растёт объём базы и время записи. Включайте версионирование только там, где история действительно нужна.
• RLS (ограничение доступа на уровне записей). Механизм полезный, но он усложняет каждый запрос. При большом числе пользователей с разными профилями доступа это заметно. Настройки RLS стоит периодически пересматривать.

Что можно проверить без программиста

Часть причин администратор или главбух может исключить сам, не дожидаясь аудита:

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

Неочевидные причины

Иногда 1С тормозит совсем не из-за 1С:

• При входе через удалённый рабочий стол программа пытается подключить локальные принтеры или торговое оборудование, которое не отвечает. Пользователь ждёт таймаута.
• Неисправное или медленное подключаемое оборудование тормозит операции, где оно участвует.
• Антивирус проверяет каталоги кэша и временные файлы 1С при каждом обращении.
• Медленный DNS или проблемы с сертификатами при обращении к внешним сервисам из кода.

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

На проектах я иду от простого к сложному и от измерений к выводам.

1. Мониторинг ресурсов сервера и клиентов: процессор, память, диски, сеть — в моменты жалоб, а не в среднем за сутки.
2. Технологический журнал платформы: события ожиданий на блокировках, таймаутов, взаимоблокировок и исключений. Он настраивается файлом logcfg.xml в каталоге настроек платформы.
3. Анализ долгих запросов в СУБД и проверка регламентного обслуживания.
4. Замер производительности конкретных операций, на которые жалуются, — чтобы увидеть строку кода, где теряется время.
5. Проверка настроек версионирования, RLS, регламентных заданий и обменов.

Минимальная настройка технологического журнала для поиска проблем с блокировками выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <!-- Каталог для логов и срок хранения в часах -->
  <log location="D:\1c_techlog" history="24">
    <!-- Ожидания на блокировках, таймауты и взаимоблокировки -->
    <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>

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

Для крупных систем есть специализированные инструменты, например центр управления производительностью из состава корпоративного инструментального пакета 1С. Он показывает оценку производительности ключевых операций и помогает доказать, что после изменений стало лучше.

Когда нужен аудит производительности

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

Чек-лист перед обращением, чтобы аудит прошёл быстрее:

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

Сроки зависят от системы: первичная диагностика — от нескольких часов до нескольких дней. Ориентир для оценки — 2 500 ₽/ч.

Коротко

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