Доступная производительность 1С: ложные алерты на простое
Доступная производительность 1С проседает ночью, когда в базе никого нет, а среднее время вызова рабочего процесса на простое вырастает до секунд. Если алерты построены прямо на этих показателях, дежурный получает предупреждения как раз тогда, когда пользователей нет. Разберём, откуда берётся этот шум, как отличить простой от настоящей нехватки ресурсов и какие правила оставить.
Что такое доступная производительность 1С
Это результат эталонного теста, который кластер периодически прогоняет на каждом рабочем процессе rphost. Чем быстрее процесс выполняет эталонную операцию, тем выше число. Кластер учитывает его, когда распределяет новые соединения между рабочими процессами, поэтому показатель полезен и для мониторинга: если он падает, процессу не хватает процессора, памяти или он ждёт диск.
Посмотреть значение можно в консоли администрирования серверов (список рабочих процессов, колонка «Доступная производительность») или через rac:
rac cluster list
rac process list --cluster=UUID_КЛАСТЕРА
Нужное поле в выводе rac называется available-perfomance — с опечаткой в названии, так его и ищите в скриптах. Обычные значения — сотни, но абсолютного эталона нет: у разных серверов и баз свой нормальный уровень. Это не APDEX, шкала не от 0 до 1, и сравнивать нужно с историей этого же сервера, а не с числом из чужой статьи.
Почему алерт по доступной производительности срабатывает на простое
Эталонный тест короткий, и на свободном сервере его результат зависит от всего, что в этот момент работает рядом: антивирус сканирует диск, ставятся обновления, идёт резервное копирование, запускается регламентное задание. Под нагрузкой пользователей эти всплески тонут в общем фоне, а на пустом сервере одна такая минута заметно роняет число.
Отсюда типичная картина: ночью или в выходные приходит «Доступная производительность ниже нормы», утром дежурный открывает графики — процессор почти свободен, пользователей нет, а к началу рабочего дня показатель вернулся сам. После нескольких таких ночей предупреждение перестают читать, и настоящую просадку под нагрузкой пропускают вместе с шумом.
Почему время вызова 1С растёт, когда никто не работает
Вторая частая ложная тревога — среднее время вызова. В rac process list у процесса есть avg-call-time, avg-server-call-time, avg-db-call-time и avg-lock-call-time. Это средние по всем вызовам процесса, включая служебные. Когда пользователей нет, в среднее попадают в основном служебные вызовы-ожидания, которые по своей природе длятся секунды. Достаточно одного открытого и брошенного тонкого клиента: сеанс делает единицы вызовов за 5 минут, а среднее по процессу показывает несколько секунд на вызов и зажигает алерт «1С тормозит».
Честнее считать по пользовательским сеансам. Команда rac session list --cluster=UUID_КЛАСТЕРА отдаёт по каждому сеансу суммы за последние 5 минут: calls-last-5min, duration-last-5min и duration-last-5min-dbms (длительности в миллисекундах). Если сложить их по сеансам, отбросив фоновые и служебные (app-id BackgroundJob, SystemBackgroundJob, JobScheduler, Designer, SrvrConsole, COMConsole, Debugger, RAS), получится среднее время вызова пользователей: сумма длительностей, делённая на сумму вызовов. И сразу появляется число, по которому видно простой, — сколько вызовов пользователи сделали за 5 минут.
Две детали для многосерверного кластера. Список сеансов отдаётся по всему кластеру, поэтому на каждом рабочем сервере считайте только сеансы его рабочих процессов, иначе одна и та же кластерная сумма придёт под именем каждого сервера и алерт продублируется. И помните, что один зависший вызов эти суммы почти не меняют: такие случаи ловит как раз доступная производительность и ожидания на блокировках.
Как отличить простой от нехватки ресурсов
Рабочая схема — два уровня с разной логикой.
Предупреждение («внимание»): доступная производительность ниже 80 % от обычного уровня этого сервера, держится 15 минут и при этом пользователи работают — вызовов пользовательских сеансов за 5 минут не меньше порога простоя (разумная отправная точка — 10). На простое предупреждение не оценивается вообще.
Критичный алерт: ниже 60 % от обычного уровня 10 минут подряд, в том числе на простое. Такая просадка уже не шум от антивируса, а нехватка ресурсов, в которую упрутся первые пользователи утром.
Для времени вызова то же правило: алерт оценивается, только если вызовов за 5 минут набралось достаточно, чтобы среднее что-то значило (порядка сотни), а пороги остаются привычными — 1 и 3 секунды на вызов сервера, 0,5 и 2 секунды на обращение к СУБД.
Почему задержка 15 минут, а не сглаживание средним за 20 минут: усреднение растягивает короткую глубокую просадку в длинную неглубокую и шумит не меньше. Задержка просто требует, чтобы проблема продержалась.
С чем сравнивать: обычный уровень вместо фиксированного числа
Фиксированный порог «ниже 200» не работает: на одном сервере это авария, на другом — норма. Обычный уровень удобно считать как 90-й перцентиль доступной производительности этого процесса за неделю, а новый сервер первые полчаса не оценивать, пока не накопится история. В PromQL-подобном языке условие выглядит примерно так: текущее значение меньше 0,8 × quantile_over_time(0.9, показатель[7d]), и при этом нет признака простоя. Подробно о порогах по остальным показателям кластера — в статье пороги мониторинга кластера 1С.
Если вы держите собственные выражения правил, проверьте их отдельно: новое условие о простое в них само не появится, и менять им задержку молча нельзя — иначе правило, которое раньше срабатывало через 10 минут, начнёт ждать 15 без вашего ведома.
Что проверить у себя
— На каком показателе построен алерт по времени вызова: avg-call-time процесса или суммы по пользовательским сеансам.
— Сколько срабатываний по доступной производительности за последнюю неделю пришлось на ночь и выходные, когда пользователей не было.
— Есть ли в правиле признак простоя — число вызовов пользовательских сеансов за 5 минут.
— С чем сравнивается доступная производительность: с фиксированным числом или с историей этого сервера.
— Не глушит ли признак простоя критичный уровень: просадка ниже 60 % должна приходить всегда.
— В многосерверном кластере — не приходит ли один и тот же алерт с каждого рабочего сервера.
— Что работает на сервере 1С в часы ночных просадок: антивирус, обновления, бэкапы, регламентные задания.
Какое значение доступной производительности считается нормальным?
Универсального числа нет: обычные значения — сотни, но уровень зависит от процессора, частоты, числа процессов и нагрузки. Нормой стоит считать историю этого же сервера за неделю, а тревожиться при устойчивом падении на 20 % и больше.
Почему бы не выключать алерты 1С ночью по расписанию?
Расписание не знает, работают ли люди: закрытие месяца, обмены и ночные смены его ломают. Признак простоя по числу пользовательских вызовов точнее и сам подстраивается под реальную работу. К тому же критичный уровень ночью нужен: просадка ниже 60 % утром ударит по всем.
Нужен ли для этого технологический журнал?
Нет: доступная производительность, средние времена процесса и суммы по сеансам читаются через rac или службу администрирования RAS, без изменений в базе. Технологический журнал нужен, когда надо найти конкретные долгие вызовы и блокировки, а не просто заметить, что стало хуже.
Как это сделано в Voltir
В Voltir так устроены правила «Доступная производительность» и «Время вызова» в мониторинге 1С: с агентом 1.17 и новее время вызова считается по пользовательским сеансам, предупреждение молчит на простое, а критичный уровень — нет; порог «Простой» и задержки меняются в портале, полная таблица порогов правил 1С и настройка алертов — в документации. Дашборды кластера можно посмотреть в живом демо, а если разбирать ночные алерты некому — есть мониторинг как услуга с дежурством. Стоимость — на странице тарифов.