Превентивная аналитика в 1С: прогнозирование падения производительности и сбоев до их возникновения

4 июля 2026 · infolimp.ru

Почему стандартный мониторинг не спасает: ловушка средних значений

Большинство администраторов 1С ориентируются на среднее время выполнения запроса, среднюю загрузку CPU или среднюю длительность сеанса. Это классическая ловушка: среднее может оставаться в норме, пока 5% самых тяжёлых операций уже перегружают сервер. Проблема проявляется внезапно, когда один из «хвостовых» запросов блокирует всю систему.

95-й перцентиль вместо среднего

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

// Псевдокод: сбор времени выполнения из журнала регистрации
// Реальный API ИТС: чтение файлов технологического журнала через ЧтениеТекста
Процедура РассчитатьПерцентиль(ПутьКЖурналу, Перцентиль = 0.95)
    Чтение = Новый ЧтениеТекста(ПутьКЖурналу);
    Времена = Новый Массив;
    Пока Истина Цикл
        Строка = Чтение.ПрочитатьСтроку();
        Если Строка = Неопределено Тогда Прервать; КонецЕсли;
        // Парсинг строки технологического журнала: извлечение длительности
        // Формат: ... ,Duration=1234, ...
        Поз = Найти(Строка, "Duration=");
        Если Поз > 0 Тогда
            Значение = Число(Сред(Строка, Поз+9, 10));
            Времена.Добавить(Значение);
        КонецЕсли;
    КонецЦикла;
    Чтение.Закрыть();
    Времена.СортироватьПоЗначению();
    Индекс = Цел(Времена.Количество() * Перцентиль);
    Сообщить("p95 = " + Времена[Индекс] + " мс");
КонецПроцедуры

Ключевой тезис: Если p95 времени выполнения запросов вырос на 30% за неделю, а среднее — на 5%, готовьтесь к сбою. Стандартные панели мониторинга этого не покажут.

Механика под капотом: как накапливаются предвестники сбоя

Сбои производительности в 1С редко возникают мгновенно. Обычно есть цепочка накопления: рост числа взаимоблокировок → увеличение времени ожидания блокировок → фрагментация временных таблиц → утечки памяти в фоновых заданиях. Каждый этап можно отследить.

Рост числа взаимоблокировок как индикатор

Взаимоблокировки (deadlocks) — один из самых ранних сигналов. Они возникают, когда два процесса держат блокировки, нужные друг другу. В технологическом журнале они фиксируются как события TLOCK с типом Deadlock. Если количество таких событий в час превышает порог (например, 5), это повод для анализа кода.

// Анализ технологического журнала на deadlock'и
Процедура ПодсчетDeadlock(ПутьКЖурналу)
    Чтение = Новый ЧтениеТекста(ПутьКЖурналу);
    Счетчик = 0;
    Пока Истина Цикл
        Строка = Чтение.ПрочитатьСтроку();
        Если Строка = Неопределено Тогда Прервать; КонецЕсли;
        Если Найти(Строка, "Deadlock") > 0 Тогда
            Счетчик = Счетчик + 1;
        КонецЕсли;
    КонецЦикла;
    Чтение.Закрыть();
    Сообщить("Deadlock'ов за период: " + Счетчик);
КонецПроцедуры

Фрагментация временных таблиц и утечки памяти

Временные таблицы в 1С (создаваемые через ПоместитьВоВременнуюТаблицу) могут фрагментироваться, если их не удалять вовремя. Это приводит к росту времени выполнения запросов, которые используют эти таблицы. Признак — увеличение количества событий DBCache с большим размером кэша. Утечки памяти в фоновых заданиях видны по росту потребления памяти процессом rphost без снижения после завершения задания.

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

Сравнение подходов: встроенные средства и внешние системы

Для превентивной аналитики можно использовать как встроенные механизмы 1С (технологический журнал, мониторинг производительности), так и внешние системы (Zabbix, ELK, Prometheus). У каждого подхода есть условия применимости.

Для небольших внедрений (до 50 пользователей) достаточно технологического журнала и скриптов на 1С. Для крупных систем (500+ пользователей) без внешней системы не обойтись — объём данных не позволит анализировать вручную.

Практическое руководство: что делать прямо сейчас

Чек-лист внедрения превентивной аналитики

1. Настройте технологический журнал на сервере 1С: включите события TLOCK, DBCache, DBMSSQL, EXCP. Установите ротацию по размеру (не более 2 ГБ на файл).
2. Собирайте метрики раз в час: количество deadlock'ов, p95 времени выполнения, размер кэша БД, количество сеансов с длительностью > 10 минут.
3. Постройте тренды за неделю: если p95 вырос на 20% за 3 дня — ищите причину в коде или в росте данных.
4. Настройте оповещения: при превышении порога deadlock'ов (например, > 10 в час) отправляйте уведомление в Telegram или email.
5. Проверяйте фоновые задания: раз в неделю анализируйте потребление памяти процессами rphost. Если после завершения задания память не освобождается — ищите утечку.

Типичные ошибки

• Игнорирование ночных регламентных заданий: многие сбои происходят из-за тяжёлых операций, запущенных ночью. Если не анализировать ночные логи, вы пропустите предвестники.
• Неучёт сезонности: в конце месяца нагрузка растёт. Сравнивайте метрики с аналогичным периодом прошлого месяца, а не с предыдущим днём.
• Среднее вместо перцентилей: как уже говорилось, среднее скрывает проблему. Всегда считайте p95 и p99.

Заключение: превентивная аналитика как культура

Прогнозирование сбоев в 1С — это не разовая настройка, а постоянный процесс. Начните с малого: настройте сбор технологического журнала, рассчитайте p95 и количество deadlock'ов. Через месяц вы увидите, какие операции реально угрожают стабильности. Внедрите оповещения — и вы перестанете тушить пожары, а начнёте их предотвращать.

Итог: Превентивная аналитика превращает администратора 1С из «пожарного» в архитектора стабильности. Инвестиция в неё окупается первым же предотвращённым сбоем.