Как найти причину высокого потребления памяти процессом rphost в 1С

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Ситуация, когда рабочий процесс rphost начинает стремительно «пожирать» оперативную память, знакома многим администраторам и разработчикам 1С. В нормальном режиме процесс может занимать 7–8 ГБ, но под нагрузкой или из-за некорректных действий пользователей этот показатель может вырасти до 30 ГБ и выше, что приводит к перезапуску процесса и временной деградации производительности всей системы. В этой статье мы подробно разберем, как вычислить «виновника» и какие инструменты для этого использовать.

Анализ показателей в консоли администрирования серверов

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

  1. Память (всего): Основной показатель. Однако стоит учитывать, что в некоторых релизах платформы здесь могут отображаться отрицательные значения. Это часто связано с переполнением 32-битного счетчика в визуальном интерфейсе консоли или спецификой подсчета, когда объем освобожденной памяти за интервал времени превышает захваченную. Если вы видите аномальное число (слишком большое или отрицательное), этот сеанс — первый кандидат на проверку.
  2. Память (5 мин): Позволяет увидеть динамику потребления за последние 5 минут. Если процесс растет прямо сейчас, эта колонка покажет, какой именно сеанс является инициатором роста.
  3. Чтение (байт) и Запись (байт) в СУБД: Если пользователь запускает тяжелый отчет «100 на 100 км», количество прочитанных данных будет исчисляться гигабайтами. Высокая активность по чтению часто коррелирует с ростом памяти, так как данные сначала выгружаются из СУБД в память сервера приложений для обработки.
  4. Время вызова (всего): Если сеанс «завис» в выполнении длительного запроса или обработки, его суммарное время вызова будет значительно выше, чем у остальных.

Рассмотрим алгоритм действий: отсортируйте список сеансов по колонке Память (всего). Если явного лидера нет, попробуйте отсортировать по Времени вызова или количеству прочитанных данных. Аномалия в любой из этих колонок обычно указывает на конкретного пользователя или фоновое задание.

Влияние пользовательских настроек и СКД

Иногда причина кроется не в объеме данных, а в том, как именно они обрабатываются. Проанализируем ситуацию с настройками отчетов. В типовых конфигурациях пользователи часто создают собственные варианты отчетов или настраивают списки.

Проблема группировок: Если пользователь настроил динамический список или отчет с группировкой по текстовому полю (например, «Комментарий» или «Содержание»), серверу приходится строить огромные индексы в памяти. Рассмотрим ситуацию: после обновления платформы или конфигурации механизмы отбора Системы Компоновки Данных (СКД) могут работать некорректно, если настройки вынесены на форму. В некоторых случаях отбор визуально стоит, но фактически не применяется на уровне СУБД, что приводит к выборке всех записей в память rphost.

В качестве профилактики попробуйте «грохнуть» (очистить) персональные настройки форм и отчетов для подозрительных пользователей. Это можно сделать через «Администрирование» — «Настройки пользователей и прав» — «Очистка настроек».

Использование Технологического журнала (ТЖ) для глубокой диагностики

Если консоль не дает однозначного ответа, нам поможет Технологический журнал. Это наиболее мощный инструмент, позволяющий увидеть, какая именно строчка кода или какой запрос вызвал всплеск потребления ресурсов. Выясним, как правильно настроить сбор событий MEMORY.

Создадим файл logcfg.xml и укажем в нем настройки для отслеживания утечек и пиков памяти. Разберем пример конфигурации:


<config xmlns="http://v8.1c.ru/7.4/config/log">
  <log location="C:\LOGS\MEMORY" history="24">
    <event>
      <eq property="Name" value="MEMORY"/>
      <gt property="Memory" value="524288"/> 
    </event>
    <property name="All"/>
  </log>
</config>

В данном примере мы логируем события MEMORY, где объем памяти превышает 512 МБ (значение указывается в КБ). Это позволит нам увидеть в логах сеанс, время и контекст выполнения кода (стек вызовов), который привел к такому потреблению. Сопоставив время из лога с временем пика в диспетчере задач, мы найдем виновную процедуру.

Лимиты и возможности версии КОРП

Если ваша организация использует лицензии уровня КОРП, мы можем применить административные меры для предотвращения падения rphost. Рассмотрим настройки в свойствах кластера:

Важно помнить, что даже в версии КОРП эти механизмы не всегда срабатывают мгновенно, поэтому программный мониторинг остается приоритетом.

Анализ на уровне операционной системы

Проанализируем ситуацию через системный монитор (PerfMon). Иногда 1С показывает внутреннюю память, но не учитывает внешние компоненты. Посмотрите на счетчик Process / Private Bytes для конкретного rphost. Если он растет, а память сеансов в консоли 1С остается стабильной, возможно, проблема в:

  1. COM-объектах: Например, при выгрузке в Excel через COM-соединение, память может выделяться внутри адресного пространства rphost, но не учитываться как «память сеанса 1С».
  2. Утечках в платформе: В некоторых релизах (включая 8.3.21) наблюдались проблемы с очисткой кэша метаданных. В таком случае помогает только регламентный перезапуск службы сервера 1С или использование скриптов для очистки серверного кэша (папки snccntxt).

Рекомендации по коду

Если вы разработчик и обнаружили, что ваш код потребляет много памяти, разберем типичные ошибки:

Работа с большими коллекциями: Попытка выгрузить результат запроса в ТаблицаЗначений, содержащую сотни тысяч строк, на стороне сервера гарантированно приведет к резкому скачку rphost. Используйте выборку (Запрос.Выполнить().Выбрать()) для последовательной обработки данных.


// Плохо: вся таблица в памяти
ТЗ = Запрос.Выполнить().Выгрузить();
Для Каждого Стр Из ТЗ Цикл
    // Обработка
КонецЦикла;

// Хорошо: данные читаются порциями
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    // Обработка
КонецЦикла;

Временные таблицы: Помните, что менеджер временных таблиц живет до тех пор, пока не уничтожен объект или не закрыто соединение. Если вы создаете огромные временные таблицы и не удаляете их явно, они продолжают занимать место в rphost (или в TempDB SQL, но с кэшированием в 1С).

Подводя итог: для поиска виновника используйте комбинацию из мониторинга сеансов (колонки Память и Чтение), анализа пользовательских настроек и настройки Технологического журнала для фиксации события MEMORY. Это позволит не только устранить текущую проблему, но и предотвратить ее появление в будущем за счет оптимизации кода или настройки лимитов сервера.

← На главную