Администрирование · 9 мин
Показатель «Захвачено СУБД» в 1С: в чём измеряется и что с ним делать
Разбираем показатель «Захвачено СУБД» в 1С: в чём он измеряется, что считается нормой, как найти источник ожиданий на блокировках и снизить нагрузку на сервер СУБД.
При анализе производительности 1С через Центр управления производительностью (1С:ЦУП), консоль кластера или средства мониторинга администраторы сталкиваются с показателем «Захвачено СУБД». Он отражает долю времени, которое рабочие процессы 1С проводят в ожидании ответа от сервера баз данных — выполнения запросов и снятия блокировок. Понимание того, в чём измеряется этот показатель и как он формируется, — ключ к диагностике «тормозов» в клиент-серверной 1С.
Показатель измеряется в процентах от общего времени работы (доли времени ожидания СУБД в суммарной длительности вызовов), а в детальных отчётах — в секундах или миллисекундах суммарного ожидания. Например, значение 60% означает, что больше половины времени сеансы простаивали, ожидая ответа СУБД. Это косвенный признак того, что узкое место находится на уровне базы данных, а не на сервере приложений или клиенте.
Важно не путать «Захвачено СУБД» с загрузкой процессора сервера СУБД. Показатель считается со стороны платформы 1С: он фиксирует, сколько времени вызовы кластера ждали ответа, независимо от того, чем в этот момент был занят SQL-сервер — реальными вычислениями или ожиданием освобождения блокировок.
Что именно измеряет показатель и в каких единицах
В Центре управления производительностью и типовых счётчиках платформы время работы сеанса раскладывается на составляющие: время на клиенте, время на сервере 1С, время ожидания СУБД («Захвачено СУБД») и время ожидания блокировок 1С. Каждая составляющая показывается как в абсолютных единицах (секунды, миллисекунды), так и в процентах от суммарной длительности.
Диагностика строится по простому правилу: какая составляющая доминирует, там и ищется проблема. Если «Захвачено СУБД» занимает основную долю, оптимизировать код на встроенном языке или менять клиентские машины бессмысленно — работать нужно с запросами, индексами, блокировками и настройками сервера баз данных.
Какие значения считать нормой, а какие — тревожным сигналом
Жёсткого норматива у показателя нет: допустимый уровень зависит от характера нагрузки. Для интерактивной работы пользователей высокая доля ожидания СУБД почти всегда означает проблему, потому что пользователь в это время видит «зависшую» форму. Для ночных регламентных заданий умеренные значения допустимы, если операции укладываются в отведённое окно.
Ориентироваться удобно не на абсолютный порог, а на динамику и симптомы: резкий рост показателя относительно обычного уровня, рост времени отклика у пользователей, появление ошибок превышения времени ожидания блокировок. Такая комбинация однозначно требует разбора.
Как проверить результат
Стабильный уровень без резких скачков, типичный для вашей базы
Резкий рост относительно обычного уровня или доминирование над другими составляющими
Операции выполняются за привычное время
Пользователи жалуются на зависания, операции растянулись
Нет ошибок ожидания блокировок и тайм-аутов запросов
Регулярные ошибки превышения времени ожидания блокировки или запроса
Как найти источник ожиданий на стороне СУБД
Первый шаг — включить технологический журнал на сервере 1С с событиями DBMSSQL (или DBPOSTGRS для PostgreSQL) и SDBL с длительностью, чтобы увидеть конкретные запросы и время их выполнения. Длительные запросы с этого момента можно сопоставить с планами выполнения на стороне СУБД.
Параллельно стоит посмотреть активные сеансы и блокировки: в MS SQL это динамические представления sys.dm_tran_locks и sys.dm_os_waiting_tasks, в PostgreSQL — представление pg_locks и pg_stat_activity. Цель — понять, чем занят сервер: выполняет тяжёлые запросы или сеансы ждут друг друга по блокировкам.
- 1Включите технологический журнал с событиями DBMSSQL и SDBL с указанием длительности
- 2Соберите статистику за период, когда наблюдаются жалобы на медленную работу
- 3Отсортируйте события по длительности и выделите самые тяжёлые запросы
- 4Проверьте планы выполнения этих запросов средствами СУБД
- 5Проанализируйте блокировки через системные представления СУБД
- 6Устраните причину: оптимизируйте запрос, добавьте индекс, пересмотрите логику транзакции
- 7Повторите замер и сравните долю «Захвачено СУБД» до и после
Типичные причины высокого значения
Чаще всего показатель раздувают четыре группы причин. Первая — неоптимальные запросы: сканирование больших таблиц вместо использования индексов, запросы в цикле, выборка лишних полей. Вторая — блокировки: длинные транзакции, обновление одних и тех же строк конкурирующими сеансами, избыточные управляемые блокировки.
Третья группа — состояние самой СУБД: устаревшая статистика, фрагментация индексов, нехватка памяти, медленные диски, ограничение tempdb в MS SQL. Четвёртая — сетевые задержки между сервером 1С и сервером СУБД, которые платформа тоже учитывает как время ожидания ответа.
Как выбрать действие
Как снизить долю ожидания СУБД
На уровне кода эффективны классические приёмы: выбирать только нужные поля, избегать запросов в цикле, использовать временные таблицы и пакетные запросы, применять конструкцию «ДЛЯ ИЗМЕНЕНИЯ» осознанно и только там, где она действительно нужна. Каждый такой приём напрямую сокращает время, которое сеанс проводит в ожидании СУБД.
На уровне администрирования помогают регулярное обновление статистики и перестроение индексов, контроль размера и настроек tempdb, разнесение файлов данных и журналов по разным дискам, достаточный объём оперативной памяти под СУБД. Для MS SQL также проверяйте настройки максимальной степени параллелизма и порога стоимости параллелизма — их неверные значения нередко дают лишние ожидания.
Частые ошибки при интерпретации показателя
Самая распространённая ошибка — трактовать высокий процент «Захвачено СУБД» как «медленный SQL-сервер» и начинать с апгрейда железа. На практике причина чаще в логике: один неоптимальный запрос в массовой операции способен «съесть» ресурсы любого сервера, и новое железо лишь отложит проблему.
Вторая ошибка — смотреть только на средний процент по всей базе. Среднее сглаживает проблему: разбивайте показатель по пользователям, операциям и временным интервалам. Третья ошибка — игнорировать блокировки: ожидание снятия блокировки тоже входит в «Захвачено СУБД», и оптимизация запросов здесь не поможет, нужна работа с транзакциями.
Как контролировать показатель постоянно
Разовый разбор решает текущую проблему, но нагрузка и объём данных меняются. Настройте регулярный сбор метрик: счётчики производительности сервера 1С и СУБД, периодический снимок длительных запросов, мониторинг ошибок ожидания блокировок в журнале регистрации. Для этого подходят как 1С:ЦУП, так и внешние системы мониторинга.
Полезно зафиксировать базовый уровень показателя в спокойный период и настроить оповещения при отклонении. Так вы узнаете о деградации до массовых жалоб пользователей и сможете связать рост ожиданий с конкретным событием: обновлением конфигурации, запуском новой обработки, ростом объёма данных.
Что важно запомнить
«Захвачено СУБД» измеряется в процентах от времени вызовов и секундах ожидания. Высокая доля направляет диагностику к запросам, блокировкам и ресурсам СУБД. Работайте по схеме: замер → поиск тяжёлых запросов и блокировок → устранение → контрольный замер.
Часто задаваемые вопросы
«Захвачено СУБД» — это загрузка процессора сервера баз данных?
Нет. Показатель считается со стороны платформы 1С и отражает время ожидания ответа СУБД. Сервер баз данных в этот момент может выполнять запрос, ждать освобождения блокировки или простаивать из-за сетевой задержки — всё это попадёт в показатель.
Какое значение показателя считать критичным?
Универсального порога нет. Ориентируйтесь на динамику относительно обычного уровня вашей базы и на жалобы пользователей. Если доля ожидания СУБД доминирует над другими составляющими времени вызовов и растёт, это повод для разбора независимо от конкретной цифры.
Входит ли ожидание блокировок в «Захвачено СУБД»?
Да, время ожидания снятия блокировок на уровне СУБД включается в этот показатель. Поэтому при высоких значениях обязательно анализируйте не только длительность запросов, но и конфликты блокировок между сеансами.
Чем смотреть показатель, если нет 1С:ЦУП?
Используйте технологический журнал с событиями DBMSSQL и SDBL — по длительности событий видно время работы с СУБД. Дополнительно помогают счётчики производительности ОС, консоль кластера и системные представления самой СУБД для анализа запросов и блокировок.
Поможет ли переход на более быстрые диски?
Только если замеры показали, что узкое место — подсистема ввода-вывода: длительные физические чтения, перегруженные диски, медленный tempdb. Если причина в неоптимальных запросах или блокировках, замена дисков даст лишь временное и частичное улучшение.
Почему показатель вырос сразу после обновления конфигурации?
Типичные причины: изменились тексты запросов, появились новые обращения к данным, сбросились или устарели планы выполнения и статистика в СУБД. Начните со сравнения тяжёлых запросов до и после обновления и обновите статистику в базе данных.