Почему 1С тормозит и где искать узкое место: замер от клиента до СУБД

Проверить скорость 1С можно за четыре шага. Сначала замерьте медленную операцию в Конфигураторе (Отладка → Замер производительности). Затем прогоните тест Гилёва на сервере. Включите технологический журнал с фильтром по длительности. И посмотрите запросы и блокировки в самой СУБД.

Жалоба «1С тормозит» почти ничего не говорит. Медленным может быть сетевой диск, перегруженный процессор сервера, кривой запрос в отчёте или чужая транзакция, которая держит блокировку. Пока вы не знаете, на каком уровне теряется время, менять железо или «чистить базу» бесполезно. Для каждого уровня есть свой инструмент и свои признаки, что виноват именно он.

Где теряется время: четыре уровня диагностики

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

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

Проверка на стороне клиента и сети

Здесь чаще всего находятся простые причины, которые чинятся без администратора базы данных.

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

Сеть до сервера. Для клиент-серверной базы проверьте задержку до сервера 1С:

ping -n 50 srv1c

В локальной сети ответ должен укладываться в 1–2 мс без потерь. Десятки миллисекунд и потери пакетов — проблема канала, а не 1С. Для удалённых офисов с задержкой 30 мс и выше тонкий клиент работает ощутимо медленнее, там выручает веб-клиент или терминальный сервер .

Локальный ПК. Что проверить на машине пользователя:

• 🛡️ антивирус: исключения для каталога кэша 1С и папки файловой базы;
• 💾 свободное место на системном диске и состояние диска;
• 🧹 кэш клиента: запуск с параметром /ClearCache безопасно сбрасывает локальный кэш метаданных;
• 🔢 разрядность и версия клиента: номер версии клиента должен совпадать с номером версии сервера.

Запуск с очисткой кэша из командной строки:

"C:\Program Files\1cv8\common\1cestart.exe" /ClearCache

Показатели производительности в клиенте. В 8.3 можно включить отображение показателей производительности в параметрах клиента (Сервис и настройки → Параметры). Платформа показывает число серверных вызовов и время последней операции. Если простое открытие формы делает десятки серверных вызовов, проблема в коде формы, а не в железе.

Встроенные средства замера: Конфигуратор и оценка производительности

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

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

1. Откройте базу в Конфигураторе и запустите отладку: Отладка → Начать отладку → Тонкий клиент.
2. В Конфигураторе включите Отладка → Замер производительности.
3. В пользовательском режиме выполните медленную операцию: проведите документ, сформируйте отчёт.
4. Снова нажмите Отладка → Замер производительности, чтобы остановить замер.
5. Отсортируйте результат по колонке времени и раскройте самые тяжёлые строки.

Чаще всего наверху оказывается выполнение запроса. Дальше смотрите, сколько раз строка вызывалась. Запрос, который выполнился 3 000 раз внутри цикла, — классическая причина тормозов проведения.

Оценка производительности (APDEX)

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

Результат выводится отчётом с оценкой APDEX от 0 до 1. Чем ближе к единице, тем больше операций укладывается в целевое время. Удобство в том, что видно динамику: после обновления релиза или переезда на новый сервер сразу понятно, стало лучше или хуже.

Тест Гилёва: быстрая проверка скорости сервера

Тест Гилёва (TPC-1C) — бесплатная внешняя конфигурация, не входит в поставку 1С. Его загружают в пустую информационную базу на том же сервере и той же СУБД, что и рабочая база. Тест выполняет типовые операции записи и чтения и выдаёт оценку в условных единицах.

Как пользоваться результатом:

• 📊 сравнивайте не с «нормой из интернета», а со своими же замерами до и после изменений;
• 🔁 запускайте тест несколько раз в разное время суток: днём под нагрузкой и ночью в тишине;
• 🧮 сравните файловый и клиент-серверный вариант на одном железе, чтобы понять вклад СУБД.

Тест хорошо выявляет слабый однопоточный процессор, медленный диск и неудачные настройки энергосбережения. Сервер 1С выполняет каждый вызов в одном потоке, поэтому частота ядра часто важнее их числа.

Тест не скажет, почему медленно проводится ваш конкретный документ. Если цифры хорошие, а пользователи жалуются, ищите в коде и блокировках.

Технологический журнал: ловим медленные запросы и блокировки

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

ТЖ настраивается файлом logcfg.xml в каталоге conf установленной платформы, например C:\Program Files\1cv8\conf\. Платформа подхватывает файл без перезапуска, примерно в течение минуты.

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

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

Значение 10000 в фильтре по duration — это одна секунда: фильтр задаётся в десятитысячных долях секунды. Параметр history="24" хранит логи 24 часа.

Без фильтров ТЖ за час занимает гигабайты и сам тормозит сервер. Всегда задавайте фильтр по событию и длительности, выносите логи на отдельный диск и выключайте журнал после сбора данных: удалите или переименуйте logcfg.xml.

Что искать в собранных логах:

• 🐢 DBMSSQL / DBPOSTGRS с большой длительностью — текст медленного запроса и контекст: из какого модуля и строки он вызван;
• 🔒 TTIMEOUT — истёк таймаут ожидания управляемой блокировки, в событии видно, кто держал блокировку;
• ♻️ TDEADLOCK — взаимоблокировка двух сеансов;
• ❗ EXCP — исключения, в том числе падения рабочих процессов.

Логи — обычные текстовые файлы. Для разбора хватает поиска по строке, а для регулярного анализа используют скрипты или инструменты из 1С:КИП.

Консоль кластера: что смотреть в сеансах и рабочих процессах

Консоль администрирования серверов 1С показывает картину нагрузки в реальном времени. Откройте кластер и раскройте Информационные базы → <ваша база> → Сеансы.

В списке сеансов добавьте колонки с временем вызовов и временем вызовов СУБД. Нужные поля можно включить через настройку колонок списка. Обращайте внимание на три вещи:

1. Сеанс с большим текущим временем вызова — он прямо сейчас что-то долго выполняет. Рядом видно пользователя и приложение.
2. Захваченное соединение с СУБД — сеанс держит транзакцию. Если таких несколько и время растёт, остальные ждут их.
3. Фоновые задания — регламентное обновление полнотекстового индекса или обмен в рабочее время легко создают нагрузку на всех.

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

Те же данные можно получить из командной строки через rac:

rac cluster list
rac session list --cluster=<id кластера>

Список полей и параметров смотрите в справке rac help session.

Проверка скорости на уровне СУБД: SQL Server и PostgreSQL

Если ТЖ показал долгие запросы, дальше идите в СУБД. Здесь видно, что именно ждёт запрос: диск, процессор или блокировку.

Microsoft SQL Server

Быстрый взгляд даёт Activity Monitor в SQL Server Management Studio: ожидания, тяжёлые запросы, дисковая активность. Для точной картины используйте системные представления.

Кто кого блокирует прямо сейчас:

SELECT session_id, blocking_session_id, wait_type, wait_time, command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Самые тяжёлые запросы с момента запуска службы:

SELECT TOP 20
  qs.total_elapsed_time / qs.execution_count AS avg_time_us,
  qs.execution_count,
  SUBSTRING(st.text, 1, 300) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY qs.total_elapsed_time DESC;

PostgreSQL

Активные запросы и их длительность:

SELECT pid, now() - query_start AS duration, state,
       wait_event_type, wait_event, left(query, 300) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

Для статистики по запросам подключите расширение pg_stat_statements и сортируйте по суммарному времени выполнения. Если в wait_event_type часто видно Lock, проблема в блокировках. Если IO — в диске.

Обслуживание базы, которое влияет на скорость

Устаревшая статистика — частая причина внезапных тормозов: оптимизатор выбирает неудачный план, и отчёт, работавший 5 секунд, начинает работать 5 минут.

Типичные причины тормозов и как их распознать

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