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

Сегодня я расскажу, как мы построили систему мониторинга своими руками, сэкономили 20% на железе (которого у нас, к слову, не «терабайты и сотни ядер», а вполне вменяемые конфигурации) и почему стандартный APDEX может нагло врать вам в лицо.

— Платформа 1С 8.3.24.

— СУБД Postgres Pro.

— Больше 40 серверов 1С в разных контурах (внутренний для сотрудников, внешний для поставщиков).

— В пике — более 4000 пользователей. Ежечасно (!) крутятся тысячи фоновых заданий и сотни интеграционных сценариев.

Меня зовут Алексей Тустик, я руковожу технической группой проектов Единого информационного пространства (ЕИП) в Гринатоме.

Контекст: что мы вообще поддерживаем

Наша система — это единое информационное пространство для закупочной деятельности. Для пользователя это выглядит как один красивый портал: фронтенд написан на Vue 3 (по модели Frontend as a Service), который через прокси и RabbitMQ общается с бэкендом. Авторизация сквозная, через JWT-токены.

До оптимизации APDEX падал ниже 0,85. Деградация шла ползучими темпами, росли жалобы. Мы создали техгруппу из трёх человек. Важный принцип: мы не превратились в чистых администраторов. Мы продолжаем кодить для проектов, чтобы не заржаветь и понимать контекст.

Почему не купили готовое?

Информационная безопасность. Почти все сервисы хотят выгружать данные вовне, а нам это запрещено.

Мы собрали свой стек:

1. Python-парсер. Скрипт по крону читает Технологический журнал (ТЖ) порциями, не съедая память. Кросс-платформенный, простой, есть везде.

2. ClickHouse. Идеальное хранилище логов. Благодаря колоночному сжатию логи четырёх нагруженных ТЖ за неделю занимают смешные 53 Гб. Настроили TTL (Time To Live), и старые данные удаляются сами.

3. Визуализация в 1С. Вместо Grafana мы сделали пустую базу 1С («Информационная база мониторинга»). Она ходит прямыми запросами в ClickHouse. Нам, одинэсникам, привычнее анализировать данные в виде табличных отчётов, а не графиков.

Запросы: смотрите на временные таблицы

Duration (время выполнения) — это не главное. В наших отчётах мы дополнительно учитываем rows affected и количество записей, помещённых во временные таблицы. Запрос может выполниться в Postgres за 0,1 сек, но вернуть 2,5 миллиона строк. Сервер 1С потратит кучу времени на обработку этого «мяса».

Анализируя цепочки событий по ConnectID, мы часто видим разрывы.
Пример: cобытие DBPOSTGRS (запрос) — 1,7 секунды. Следующее событие ТLOCK (запись) — через 6 минут. Где была система? Она 6 минут переваривала огромную выборку внутри памяти сервера приложений. Стандартный замер СУБД вам этого не покажет.

Ещё пример силы SQL: благодаря оконным функциям в ClickHouse мы нашли уникальный кейс — пользователь с контекстом «Консоль запросов» попытался выбрать 246 миллионов строк. Обычными логами такое поймать сложно, а тут сразу видно героя.

Блокировки

В самописных конфигурациях блокировки — бич системы. Многие строят сложные диаграммы Ганта для их анализа. Мы поступили проще: обычный список с условным оформлением.

Зелёным подсвечиваем жертву, красным — виновника. Этого достаточно, чтобы понять, кто кого держит, и пойти бить по рукам.

Мониторинг размеров таблиц

Мы следим за размером таблиц не только в гигабайтах, но и в количестве записей. Это позволяет ловить ситуации, когда разработчики начинают писать свои логи в регистры. Таблица может ещё не весить много, но взрывной рост количества строк (на миллионы за день) — это сигнал тревоги.

Ловушки с APDEX

Мы считаем «Дельта-APDEX» (вклад операции в общее замедление), но к самим цифрам относимся с подозрением.

В стандарте 1С операция считается успешной (зелёной), если она уложилась во время. Даже если она упала с ошибкой! Мы видели отчёты с идеальным APDEX 1,00, где пользователи не могли работать из-за ошибок кода. Поэтому всегда смотрите на счётчик ошибок в журнале регистрации.

Есть ещё ловушка, которую сложно объяснить бизнесу. Пользователь открывает список документов, ищет там контрагента «Вася», а потом нажимает кнопку «Провести и закрыть».

Механизм замеров времени может засечь время всей активности, в том числе реакцию на диалоговые окна. В итоге в метрику «Проведение документа» попадает время, которое тормозил динамический список при поиске «Васи».

Вы видите в отчёте: «Проведение РТУ — 3 минуты». Лезете в логи СУБД — там транзакция длилась 0,5 секунды. И вы никогда не поймёте, в чём дело, если не будете знать этот нюанс.

Примеры оптимизаций

1. Замирания в начале часа (Platform Issue)

Система фризила в начале каждого часа. Виновником оказался механизм ротации логов ТЖ в платформе 8.3.24 — при удалении старых файлов процесс подвисал.

Отключили штатное удаление, написали скрипт на Linux, который чистит файлы сам. Фризы ушли.

2. RLS: хеш против битовых масок

В производительном RLS 1С использовала битовую маску (2^N) для кодирования наборов групп. Когда групп стало больше 40 000, Postgres выдал ошибку row is too big (число не влезало в страницу).

Решение: заменили степени двойки на хеш от списка групп. Это убрало ошибку и дало прирост скорости расчёта прав в 10 раз.

Мы сообщили в 1С, и в БСП 3.1.11.255 это уже исправлено.

3. Расчёт места (Linux-way)

Вместо тяжёлого запроса к базе «просуммируй мне размер всех файлов», мы просто вызываем команду df через скрипт. Нагрузка на БД — ноль.

Итог

Внедрив эту систему, мы подняли APDEX до 0,99, снизили простои до минимума и сэкономили 20% бюджета на железо. Доказали, что даже в огромных системах порядок наводится не покупкой серверов, а внимательным анализом кода и логов.