Сеанс держит соединение с СУБД: как читать поле в консоли серверов 1С
Содержание
Пользователь пишет: «1С висит уже десять минут». Вы открываете консоль администрирования серверов, заходите в сеансы информационной базы и видите у одного из них в колонке «Захвачено СУБД» значение, которое не меняется и не обнуляется. Остальные сеансы при этом ждут. Это и есть типичная ситуация, когда в консоли кластера 1С «захвачено СУБД» превращается из справочной цифры в симптом проблемы.
Коротко: поле показывает, что сеанс сейчас держит соединение сервера 1С с СУБД и выполняет через него запрос. Если значение быстро сменяется, всё нормально. Если один и тот же сеанс «сидит» на СУБД минутами, надо выяснять, что он там делает: тяжёлый запрос, блокировку или зависшую транзакцию.
Что показывает поле и почему оно не всегда проблема
Сервер 1С не пускает пользователя к базе напрямую. Клиент обращается к рабочему процессу кластера, а рабочий процесс уже ходит в СУБД (PostgreSQL, MS SQL Server и другие) по своим соединениям. Пока сеанс выполняет запрос к СУБД, он занимает такое соединение. В консоли это видно в свойствах сеанса: какое соединение с СУБД занято и как давно.
В утилите rac те же данные приходят в полях db-proc-info (идентификатор серверного процесса СУБД), db-proc-took (сколько сеанс держит соединение) и db-proc-took-at (когда взял). Полный список полей выводит rac session list --cluster=<идентификатор кластера>, а если не уверены в синтаксисе, откройте rac help.
Что считать нормой:
- 🟢 Значение появляется на доли секунды и исчезает. Сеанс сделал запрос, получил ответ и отпустил соединение.
- 🟢 Несколько сеансов одновременно показывают небольшие значения. Это обычная нагрузка в рабочий день.
- 🔴 Один сеанс держит соединение минуты и больше, а пользователи жалуются на «зависание». Это повод копать.
- 🔴 Значение у сеанса не меняется, хотя пользователь давно закрыл программу. Сеанс «завис» на стороне сервера.
Единичный долгий запрос не аварийная ситуация. Закрытие периода, пересчёт себестоимости, формирование большого отчёта легально занимают СУБД на минуты. Сначала узнайте, что делает пользователь, и только потом трогайте его сеанс.
Откуда берутся долгие захваты
Причин немного, и они повторяются из базы в базу.
Тяжёлый запрос без подходящего индекса
Отчёт или обработка гоняет выборку по миллионам строк. СУБД честно работает, соединение занято. Классика: отчёт по остаткам за несколько лет без отбора по организации или складу.
Управляемая блокировка и ожидание в очереди
Один сеанс записывает документ в транзакции и держит блокировку. Второй хочет те же данные и ждёт. Со стороны консоли видно, что у ожидающего «захвачено СУБД» растёт, хотя работу делает не он. Ищите не того, у кого цифра больше, а того, кто первым начал транзакцию.
Длинная транзакция
Проведение документа с тысячами строк или групповая обработка справочника внутри одной транзакции. Пока она не завершена, все блокировки живут.
Взаимная блокировка на уровне СУБД
Два сеанса держат ресурсы друг друга. СУБД обычно сама находит такой тупик и откатывает одну из транзакций, но на это нужно время, а настройки таймаутов у разных СУБД отличаются.
Сеанс, потерявший клиента
Пользователь выключил компьютер, оборвался интернет или RDP-сессия закрылась. Клиента уже нет, а на сервере сеанс ещё живёт до таймаута и продолжает держать соединение с СУБД, если был в середине запроса.
| Причина | Как проявляется | Кто виноват |
|---|---|---|
| Тяжёлый запрос | Один сеанс, высокая нагрузка на процессор или диск СУБД | Код отчёта, отсутствие индексов |
| Ожидание блокировки | Много сеансов «висят», один явный лидер | Длинная транзакция лидера |
| Взаимная блокировка | Два-три сеанса ждут друг друга | Порядок захвата ресурсов в коде |
| Оборванный клиент | Сеанс без активности, но с захватом | Сеть, закрытый терминал |
Как найти виновника, не ломая работу остальных
Порядок такой: от безопасного к рискованному. Пока вы просто смотрите, пользователей это не затрагивает.
Шаг 1. Посмотрите сеансы
В консоли администрирования раскройте нужный кластер, затем Информационные базы, выберите базу и откройте узел Сеансы. Отсортируйте по времени последней активности и по вызовам. Запишите имя пользователя, приложение (тонкий клиент, веб-клиент, фоновое задание) и время начала.
Фоновые и регламентные задания тоже видны в списке сеансов. Часто виновник не человек, а ночное закрытие месяца или обмен, который не уложился в окно.
Шаг 2. Свяжите сеанс с процессом в СУБД
Идентификатор из db-proc-info совпадает с идентификатором серверного процесса в СУБД. В PostgreSQL его можно найти в представлении pg_stat_activity:
SELECT pid, state, wait_event_type, wait_event, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;
В MS SQL Server аналог — динамические представления sys.dm_exec_requests и sys.dm_tran_locks, а для беглого взгляда удобен стандартный монитор активности в SSMS.
Если wait_event_type показывает ожидание блокировки, значит, этот процесс сам кого-то ждёт, и надо искать блокирующий. В PostgreSQL ответ даёт функция pg_blocking_pids(<pid>).
Шаг 3. Спросите человека
Это самый недооценённый способ. Позвоните пользователю из сеанса и узнайте, что он запускал. Нередко выясняется, что он закрыл окно, но обработка продолжает работать, или что запускали сразу три отчёта.
Шаг 4. Включите технологический журнал, если причина неясна
Для повторяющихся проблем настройте технологический журнал (файл logcfg.xml в каталоге conf платформы). Нужны события, связанные с долгими вызовами СУБД и блокировками. Журнал растёт быстро, поэтому включайте его на ограниченное время и с отбором по длительности, иначе забьёте диск.
Как снять блокировку, ничего не потеряв
Прежде чем завершать сеанс, предупредите владельца: несохранённые данные в этом окне пропадут, а транзакция откатится. Если это закрытие месяца или длинная групповая обработка, откат может занять столько же времени, сколько работа шла до этого.
Способы, от мягкого к жёсткому:
- Подождать. Если запрос реально выполняется и пользователь понимает, чем занят, дайте ему завершиться. Просто пометьте для себя время и вернитесь к проверке.
- Попросить пользователя закрыть программу. Корректный выход завершает сеанс сам и освобождает соединение.
- Завершить сеанс в консоли. Выберите сеанс, в контекстном меню нажмите
Удалить. Или командой:rac session terminate --cluster=<id кластера> --session=<id сеанса>. Идентификаторы берите изrac cluster listиrac session list. - Завершить процесс в СУБД. Если после завершения сеанса соединение осталось занятым, снимите запрос в самой СУБД:
pg_terminate_backend(<pid>)в PostgreSQL или командаKILL <spid>в MS SQL Server. Это откатывает незавершённую транзакцию. - Перезапустить рабочий процесс. В консоли откройте узел
Рабочие процессыи завершите нужный процесс. Кластер поднимет новый, но все сеансы, обслуживаемые этим процессом, оборвутся. Делайте это в нерабочее время или после предупреждения людей.
Службу сервера 1С (1C:Enterprise 8.3 Server Agent) останавливают только в крайнем случае: рухнут сразу все сеансы всех баз.
rac session terminate. Данные несохранённого окна и так потеряны.db-proc-info и снимите его средствами СУБД.Ограничение числа соединений с СУБД
Соединения с СУБД не бесконечны. У СУБД есть собственный лимит одновременных подключений (в PostgreSQL — параметр max_connections), а у кластера 1С — свои настройки рабочих процессов и числа соединений на процесс. Если соединений мало, сеансы выстраиваются в очередь: один занял, остальные ждут, и вы видите массовые «захваты».
Как смотреть:
- 📌 Сколько соединений открыто сейчас: в PostgreSQL посчитайте строки в
pg_stat_activity, в MS SQL Server — число сессий вsys.dm_exec_sessions. - 📌 Сколько разрешено: параметр
max_connectionsвpostgresql.confлибо ограничение на уровне экземпляра MS SQL Server. - 📌 Сколько рабочих процессов и каких: в консоли узел
Рабочие серверы, в свойствах сервера и в настройках требований назначения функциональности.
Что делать, если упёрлись в лимит:
- Сначала проверьте, нет ли «утечки» зависших сеансов. Если их десятки, причина в них, а не в лимите.
- Затем оцените нагрузку: сколько пользователей, сколько баз на одном сервере СУБД.
- Только потом повышайте лимит и добавляйте ресурсы. Простое увеличение
max_connectionsбез запаса по памяти может обернуться нехваткой оперативной памяти на сервере СУБД: каждое соединение потребляет её.
Если на одном сервере СУБД живёт несколько информационных баз, лимит делится между ними. Одна «шумная» база способна выбрать почти все соединения и затормозить остальные.
Нюансы PostgreSQL и MS SQL Server
Консоль кластера одинакова для обеих СУБД, а вот инструменты диагностики разные.
| Вопрос | PostgreSQL | MS SQL Server |
|---|---|---|
| Активные запросы | pg_stat_activity | sys.dm_exec_requests, монитор активности |
| Кто кого блокирует | pg_blocking_pids(pid) | sys.dm_tran_locks, поле blocking_session_id |
| Снять запрос | pg_cancel_backend, pg_terminate_backend | KILL <spid> |
| Типичная особенность | Раздувание таблиц без регулярного обслуживания | Эскалация блокировок до уровня таблицы |
Отдельно про обслуживание. Если у базы давно не выполнялись регламентные операции (обновление статистики, очистка мёртвых версий строк в PostgreSQL, перестроение индексов в MS SQL Server), запросы идут по плохим планам. СУБД держит соединения дольше, и «захвачено» растёт без видимой причины в коде. Проверьте, настроены ли такие задачи по расписанию.
Что сделать, чтобы захваты не повторялись
Профилактика сводится к дисциплине и мониторингу.
- ✅ Разведите по времени тяжёлые регламентные задания: не запускайте обмен, пересчёт итогов и резервное копирование одновременно.
- ✅ Выносите тяжёлые отчёты в фоновые задания или на нерабочее время, а не запускайте их в пик.
- ✅ Следите за длинными транзакциями: в пользовательском коде не держите транзакцию открытой на время долгой обработки.
- ✅ Настройте автоматическое завершение неактивных сеансов по таймауту, чтобы потерянные клиенты не копились.
- ✅ Заведите оповещение: если сеанс держит СУБД дольше порога (например, пяти минут), администратор получает сообщение.
- ✅ Регулярно обслуживайте базу на уровне СУБД: статистика, индексы, очистка.
Когда без специалиста не обойтись
Своими силами разумно разобрать простые случаи: оборванный клиент, одиночный тяжёлый отчёт, переполнение соединений. Дальше нужен человек с опытом.
Зовите администратора СУБД или программиста 1С, если:
- блокировки повторяются каждый день в одно и то же время;
- виновник — типовой документ или регламентное задание, и непонятно, что с ним делать;
- в технологическом журнале видны взаимные блокировки в одном и том же месте кода;
- завершение сеансов не помогает, а производительность падает после каждой перезагрузки процесса;
- сервер СУБД упирается в диск или память, и нужно пересматривать конфигурацию железа.
Подготовьте для специалиста: время инцидента, имя пользователя и приложение, идентификатор сеанса, значения db-proc-info и фрагмент вывода pg_stat_activity или монитора активности. С этим разбор занимает минуты, а не часы.