Кто тормозит базу: сеансы, запросы, блокировки или сеть

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

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

С чего начать диагностику: где именно тормозит

Сначала определите масштаб. От ответа зависит, какой инструмент брать.

Параллельно откройте на сервере «Диспетчер задач» Windows или top/htop в Linux. Три цифры сразу отсекают половину гипотез:

• 🔥 Процессор под 100% — смотрите, какой процесс: rphost.exe (рабочий процесс 1С) или sqlservr.exe/postgres.
• 💾 Свободной памяти почти нет — рабочие процессы 1С и СУБД конкурируют за RAM, начинается подкачка.
• 📀 Очередь к диску высокая — СУБД читает с диска то, что не поместилось в память, или идёт резервное копирование .

Мониторинг сеансов в консоли администрирования серверов 1С

Консоль кластера — главный инструмент, когда база работает в клиент-серверном варианте. В файловом варианте её нет: там переходите сразу к разделу о клиенте и сети.

Как найти тяжёлый сеанс

1. Запустите «Администрирование серверов 1С Предприятия» и подключитесь к центральному серверу.
2. Раскройте Кластеры → <ваш кластер> → Информационные базы → <база> → Сеансы.
3. Через контекстное меню списка добавьте колонки с текущим временем вызова, временем вызова СУБД, захватом СУБД, процессорным временем и объёмом данных за последние 5 минут.
4. Отсортируйте по «Время вызова (текущее)» по убыванию.

Сеанс, у которого текущий вызов идёт десятки секунд, и есть первый подозреваемый. В строке видно пользователя, компьютер и приложение (тонкий клиент, фоновое задание, COM-соединение).

Как читать колонки

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

Рабочие процессы

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

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

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

Куда положить logcfg.xml

Файл кладут в каталог conf платформы на сервере 1С:

• C:\Program Files\1cv8\conf\ — действует для всех установленных версий;
• C:\Program Files\1cv8\8.3.xx.xxxx\bin\conf\ — только для конкретной версии.

Перезапуск службы не нужен: платформа перечитывает настройку примерно раз в минуту.

Пример настройки на поиск тормозов

Конфигурация ниже пишет вызовы и запросы дольше одной секунды, а также все события блокировок. В 8.3 длительность в ТЖ указывается в микросекундах, поэтому одна секунда — 1000000.

<?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="CALL"/>
      <ge property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="DBMSSQL"/>
      <ge property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="DBPOSTGRS"/>
      <ge property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="TLOCK"/>
      <ge property="duration" value="1000000"/>
    </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>

history="24" — хранить 24 часа. Каталог D:\TechLog создайте заранее на диске, где много места.

ТЖ без фильтра по длительности за час может заполнить диск сервера до отказа. Включайте его на время диагностики и не ставьте каталог на системный диск или диск с базами.

Что искать в логах

• ⏱ CALL с большой длительностью — какой вызов долгий; в свойствах есть пользователь и контекст (модуль и строка кода).
• 🗄 DBMSSQL / DBPOSTGRS — текст запроса к СУБД и его длительность; рядом идёт идентификатор соединения СУБД, по нему сеанс сопоставляют с процессом в СУБД.
• 🔒 TLOCK — ожидание управляемой блокировки 1С, в свойствах видно, какое пространство блокировок и кто его держал.
• ⛔ TTIMEOUT — блокировку не дождались; у пользователя при этом ошибка Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки.
• 💥 TDEADLOCK — взаимоблокировка двух сеансов.

Логи — текстовые файлы по часам. Для разбора удобна связка findstr/grep или сторонние анализаторы ТЖ. Простой пример — найти все ожидания блокировок дольше 5 секунд в Linux-окружении или WSL:

grep -h ",TLOCK," */*.log | awk -F'-' '{split($2,a,","); if (a[1]+0 > 5000000) print}' | head -50

Запросы к СУБД и ожидания блокировок

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

Microsoft SQL Server

В SQL Server Management Studio выполните запрос — он покажет активные запросы, кто кого блокирует и текст SQL:

SELECT r.session_id,
       r.blocking_session_id,
       r.status,
       r.wait_type,
       r.wait_time,
       r.cpu_time,
       r.logical_reads,
       t.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.session_id <> @@SPID
ORDER BY r.cpu_time DESC;

• Ненулевой blocking_session_id — запрос ждёт другой сеанс. Ищите «голову» цепочки: тот, кто блокирует, но сам никого не ждёт.
• Большие logical_reads — запрос читает слишком много страниц: нет подходящего индекса, условие не по индексу, отчёт без отбора.
• wait_type с префиксом LCK_ — блокировки на уровне СУБД, PAGEIOLATCH_ — ожидание диска.

PostgreSQL

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

Состояние idle in transaction долгое время — сеанс открыл транзакцию и держит её. Непустой blocked_by — список процессов, которые мешают этому.

Почему 1С тормозит из-за блокировок

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

Диагностика рабочего места пользователя и сети

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

Компьютер пользователя

• 🧠 Память. Толстый клиент и браузер с десятком вкладок на 4 ГБ RAM — гарантированные тормоза. Посмотрите в диспетчере задач процесс 1cv8c.exe (тонкий клиент) или 1cv8.exe (толстый).
• 🛡 Антивирус. Проверка на лету каталога кэша и временных файлов 1С заметно замедляет работу. Добавьте каталоги 1С в исключения по согласованию с безопасниками.
• 🗂 Кэш клиента. Испорченный или раздутый кэш даёт медленный старт и странные ошибки. Очистите его ключом /ClearCache в строке запуска или удалением кэша в окне выбора баз.

Строка запуска с очисткой кэша:

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

Сеть

Тонкий клиент к серверу 1С терпимо работает и по медленному каналу. Файловая база по сети — нет: каждое чтение идёт через общую папку, и задержка 5–10 мс уже ощутима.

1. Проверьте задержку до сервера: ping -n 50 <сервер>. Потери пакетов и скачки — повод звать сетевиков.
2. Посмотрите, как подключена база в списке баз: файловая по пути \\сервер\папка или серверная.
3. Для удалённых офисов используйте тонкий клиент к серверу или веб-клиент через публикацию, а не файловую базу по VPN.

Файловый вариант

В файловой базе нет консоли кластера и ТЖ по запросам СУБД в привычном виде. Нагрузку смотрят на компьютере, где лежит файл 1Cv8.1CD: загрузка диска, антивирус, сколько людей работает одновременно. Если пользователей больше 5–10 и они постоянно мешают друг другу — пора думать о переходе на клиент-серверный вариант.

Встроенные средства производительности в 1С

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

Этот инструмент показывает, какая строка кода тратит время. Нужен доступ к Конфигуратору и включённая отладка.

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

Результат — список строк модулей с числом вызовов, временем и процентом от общего. Строка с 60–80% времени и есть узкое место. Обычно это запрос в цикле или выборка без отбора.

Оценка производительности в типовых конфигурациях

В БП 3.0, ЗУП 3.1, УТ 11 и других конфигурациях на БСП есть подсистема оценки производительности. Её включают в разделе Администрирование → Обслуживание, группа «Оценка производительности». После включения программа сама замеряет время ключевых операций (открытие форм, проведение документов) и считает показатель APDEX.

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

Журнал регистрации

Журнал регистрации не измеряет время, но помогает найти виновника по времени жалобы. Отфильтруйте события по интервалу, когда всё «висело», и посмотрите, кто запускал закрытие месяца, обработку или загрузку данных.

Сторонние утилиты и системы мониторинга

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

В perfmon для начала достаточно трёх счётчиков:

• Processor(_Total)\% Processor Time — загрузка процессора;
• Memory\Available MBytes — свободная память;
• LogicalDisk(*)\Avg. Disk sec/Read — задержка чтения диска. Значения стабильно выше 20 мс для диска с базами — тревожный знак.

Частые вопросы о поиске причин тормозов 1С