Алгоритм расследования мёртвого кэша и утечек памяти в 1С
База данных - Технологический журнал
Коллеги, я собрала здесь реальные причины деградации кластера 1С: от неконтролируемого потребления памяти до ложных срабатываний технологического журнала. Представляю вам практическое руководство по локализации утечек (без устаревших паттернов и пустой теории).
1. Архитектура памяти 1С: rphost, rmngr и специфика кэширования
Ошибочно считать процесс rphost единственным виновником нехватки памяти. В высоконагруженных системах критическую роль играет rmngr (менеджер кластера), кэширующий сеансовые данные, управляющий блокировками и полнотекстовым поиском. Утечки в rmngr способны обрушить кластер не реже, чем тяжелый BSL-код в рабочих процессах.
Анализируя метрику Private Bytes, необходимо отличать утечку от прогрева кэша платформы. После рестарта службы 1С агрессивно кэширует скомпилированные модули и метаданные. Линейный рост в первые часы работы — это штатный прогрев. Настоящая утечка диагностируется только тогда, когда потребление не останавливается после пробития лимитов платформы и не снижается при падении пользовательской нагрузки.
| Системная метрика | Описание | Ключевой фактор для аудита |
|---|---|---|
| Private Bytes (Commit) | Виртуальная память, эксклюзивно запрошенная процессом у ОС. | Главный индикатор утечки памяти только на длинной дистанции (после прогрева кэша). |
| Working Set | Объем физической RAM, занятый страницами процесса в данный момент. | Метрика может скрывать утечку, если неактивные страницы вытесняются в своп. |
| Page File Usage (Своп) | Память, выгруженная на диск из-за дефицита физической RAM. | Критический триггер деградации производительности (появление фризов и таймаутов). |
2. Истинные источники «мёртвого кэша»
Мёртвый кэш — это структуры, удерживаемые в памяти из-за активных входящих ссылок. Современный сборщик мусора 1С успешно разрешает простые циклические ссылки объектов, однако существуют зоны риска, которые сборщик мусора обойти не в силах.
| Объект / Механизм | Механика утечки и риски |
|---|---|
| Пулы сеансов (HTTP-сервисы) | Сеанс HTTP-сервиса не уничтожается после ответа, а засыпает. Мутабельные переменные и временное хранилище без явной очистки остаются в rphost навсегда. Особенно это критично при обработке тяжелых JSON-пайплайнов (например, подготовка векторных данных для RAG-ассистентов или поисковых API). |
| COM-объекты | Неконтролируемое создание Excel.Application или внешних коннекторов без явного вызова методов закрытия и обнуления переменных. |
| Кэш общих модулей | Передача мутабельных коллекций (Массив, Структура, ТЗ) в параметры кэшируемой функции. Платформа плодит дублирующие ветки кэша при любом изменении исходной коллекции. |
| Транзакционный кэш | Накопление данных монолитной транзакции при длительной обработке выборок без порционной фиксации (батчинга). |
3. Ловушки Технологического журнала
Сбор метрик Memory и MemoryPeak — мощный инструмент, но фильтрация событий со скачками свыше 100 МБ помогает отловить только тяжелые, неоптимальные запросы. Настоящая утечка имеет накопительный характер: тысячи вызовов могут забирать по 1 МБ, не освобождая их. Представленный ниже XML ловит именно «слонов», которые могут стать причиной резкого срабатывания лимитов безопасности.
4. Иллюзия анализа нативных C++ дампов
Снятие дампов через утилиты вроде procdump -ma генерирует файлы, содержащие нативный код кучи C++. Поскольку фирма «1С» (в отличие от Microsoft) не предоставляет отладочные символы (PDB-файлы) в открытый доступ, самостоятельный анализ дампа в WinDbg бессмысленен. Вы не сможете транслировать шестнадцатеричные адреса обратно в имена объектов метаданных или структуры BSL. Снятие дампа — это процедура исключительно для передачи фактуры в официальную техподдержку 1С.
5. Транзакционный паттерн: защита от Deadlock
Обработка тяжелых выборок требует порционной фиксации данных (батчинга) для сброса кэша блокировок. Но код без перехвата исключений оставляет зависшие транзакции при первой же ошибке, вызывая глобальные таймауты (Lock timeout). Единственно верный паттерн — использование конструкции Попытка/Исключение.
6. Временное хранилище и пулы HTTP-сервисов
Помещение данных во временное хранилище без UUID формы — классическая утечка. В пулах сеансов веб- и HTTP-сервисов этот антипаттерн приводит к катастрофе. Если интеграционный код поместил бинарный файл в хранилище без привязки к уникальному идентификатору, он останется в памяти rphost даже после отправки HTTP-ответа 200 OK, ожидая переиспользования заснувшего сеанса.
7. Архитектурный контроль и инструменты
Статические анализаторы (SonarQube с BSL LS) полезны, но они не способны полностью отследить передачу мутабельных параметров в кэшируемые модули из-за динамической типизации 1С. Полагаться исключительно на статический код-анализ нельзя. Архитектура стабильного кластера строится на следующих правилах:
- Жесткие лимиты рабочих процессов: Настройте параметры «Безопасный расход памяти за один вызов» (пресекает тяжелые неоптимальные вызовы) и «Максимальный объем памяти рабочих процессов» (запускает мягкий рестарт
rphostбез потери сеансов при накоплении утечек). - Строгий Code Review: Ручной контроль отсутствия коллекций в сигнатурах кэшируемых функций и контроль очистки пулируемых HTTP-сеансов.
- Осторожность со сбросом кэша: Метод
ОбновитьПовторноИспользуемыеЗначения()под высокой нагрузкой может вызвать асинхронный шквал запросов (Cache Stampede), приводящий к просадке CPU и мнимому зависанию баз.
Чеклист аудита потребления памяти в 1С
| Область проверки | Критерий успеха | Статус |
|---|---|---|
| Технологический журнал | Настроен синтаксически корректный logcfg.xml для перехвата CALL/SCALL > 100 МБ для отсева "тяжелых" запросов. | [ ] Выполнено |
| HTTP/Web-сервисы | Код интеграционных шлюзов содержит явные вызовы обнуления коллекций и очистки временного хранилища перед возвратом ответа. | [ ] Выполнено |
| Кэш функций | В общие модули "Повторное использование" передаются только скалярные примитивные типы или ссылки. | [ ] Выполнено |
| Батчинг транзакций | Циклы обработки обернуты в Попытка/Исключение с обязательным вызовом ОтменитьТранзакцию() при сбоях. | [ ] Выполнено |
| Параметры кластера | Установлены лимиты "Безопасного расхода на вызов" и параметры мягкого рестарта рабочих процессов. | [ ] Выполнено |
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
