← На главную

Многие системные администраторы и специалисты 1С рано или поздно сталкиваются с ситуацией, когда рабочий процесс сервера 1С (rphost) начинает неконтролируемо потреблять оперативную память. Нередки случаи, когда из доступных 32 ГБ один процесс забирает 20-25 ГБ, что приводит к зависаниям, "тормозам" и аварийному завершению работы пользователей с ошибками нехватки памяти. Перезапуск службы спасает, но лишь на короткое время. Давайте вместе разберем эту проблему по шагам, проанализируем причины утечек и рассмотрим эффективные методы стабилизации работы кластера 1С.

Поиск неоптимального кода с помощью Технологического журнала

Первое, что мы должны понимать — процесс rphost редко "съедает" память просто так. Зачастую корень проблемы кроется в недрах конфигурации: в неоптимизированных запросах, объемных выборках данных или циклических ссылках, которые не очищаются сборщиком мусора. Просматривать миллионы строк кода вручную бессмысленно. Настроим Технологический журнал (ТЖ) для локализации проблемы (для удобства сбора данных можно использовать инструмент переноса логов ТЖ в ClickHouse).

Сфокусируемся на событиях вызова сервера. Нас интересуют события CALL и SCALL. У этих событий есть два важнейших показателя:

1. memory — текущий объем памяти, выделенный под вызов.
2. memorypeak — пиковое потребление памяти в процессе выполнения серверного вызова.

В идеальной ситуации после завершения вызова значение memory не должно постоянно увеличиваться (память должна высвобождаться). Найдем в логах ТЖ контексты, которые генерируют наибольшее значение memorypeak, и передадим эту информацию программистам для оптимизации конкретных алгоритмов.

Ограничение памяти на процесс в настройках кластера

Если быстро переписать код невозможно, применим административные меры. Начиная с версии платформы 8.3.19, свойство "Временно допустимый объем памяти процессов" доступно даже для лицензий уровня ПРОФ (ранее этот функционал был привилегией КОРП). Однако здесь кроется самая частая ошибка.

Важное правило: Настройка допустимого объема памяти применяется не ко всему серверу целиком, а к каждому отдельному рабочему процессу. Если вы впишете туда общий объем ОЗУ сервера (например, 20-30 ГБ), кластер не будет корректно управлять процессами, что наглядно продемонстрирует Монитор кластеров серверов.

Что будет, если ограничить процесс слишком жестко (например, 10 ГБ)? Вы столкнетесь с "плато потребления". Процесс упрется в лимит в 10 ГБ, перестанет выделять новую память, и сервер начнет критически тормозить. Пользователи будут жаловаться на зависания.

Правильный подход — установить разумный лимит (например, 3-4 ГБ на один rphost) и настроить резервные рабочие процессы. Когда активный процесс достигнет лимита, кластер пометит его как неактивный. Новые сеансы перестанут на него назначаться, а текущие будут плавно переведены на резервный процесс. После этого "раздутый" процесс безопасно завершится.

Настройка интервала перезапуска рабочих процессов

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

Выберем оптимальное время. Часто администраторы ставят интервал в 86400 секунд (24 часа). Здесь есть два важных нюанса:

1. Отсчет времени начинается с момента старта конкретного процесса, а не от начала суток. Если резервный процесс стартовал в 11:30 из-за пиковой нагрузки, то его плановый перезапуск произойдет ровно через сутки в 11:30. В этот момент пользователи могут заметить кратковременную паузу, пока новый процесс загружает метаданные в кэш.
2. Нужно учитывать длительность фоновых заданий. Если у вас тяжелое "Закрытие месяца" выполняется 10 часов, а вы поставили интервал перезапуска в 2,5 часа (9000 секунд), задание никогда не завершится — кластер будет убивать процесс, и задание начнет выполняться заново. Всегда анализируйте длительность самых тяжелых регламентных операций перед установкой интервала.

Обновление технологической платформы

Иногда проблема кроется не в вашем коде и не в настройках, а в самой платформе 1С. Разработчики вендора регулярно выпускают обновления, исправляющие технологические баги и утечки памяти в ядре.

Рассмотрим реальный пример: на версии 8.3.20 система могла неконтролируемо поглощать до 110 ГБ ОЗУ, сопровождая это зависаниями. Обновление до стабильного релиза (например, 8.3.21) снижало потребление до адекватных 50 ГБ и полностью устраняло зависания. Если ТЖ не показывает явных проблем в коде, а процессы растут равномерно — запланируйте тестовое обновление платформы.

Оптимизация смежных систем (СУБД, ЖР, Антивирус)

Для комплексного решения проблемы давайте проведем профилактику на уровне сервера баз данных и операционной системы:

1. Очистка процедурного кэша СУБД: Если вы используете MS SQL Server, иногда полезно очищать кэш планов выполнения запросов, чтобы сервер перестроил их оптимально. Добавьте в план обслуживания конструкцию: DBCC FREEPROCCACHE;
2. Обслуживание PostgreSQL: Если база работает на PostgreSQL, не забывайте про регулярное выполнение процедуры Full vacuum средствами самой СУБД для очистки мертвых кортежей.
3. Оптимизация Журнала регистрации (ЖР): Огромные файлы ЖР сильно тормозят сервер, как и бесконтрольное разрастание таблиц в БД, которое поможет выявить SQL Базомер. Настройте разделение ЖР по месяцам. Старые периоды (старше 3 месяцев) переносите в архивный каталог на другой физический диск.
4. Исключения антивируса: Стороннее ПО может вызывать утечки. Убедитесь, что рабочие каталоги сервера 1С (особенно папка srvinfo) и исполняемые файлы платформы добавлены в исключения антивируса. Постоянное сканирование временных файлов сеансов блокирует их своевременное удаление.

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