Многие системные администраторы и разработчики сталкиваются с ситуацией, когда серверное окружение 1С:Предприятие начинает вести себя нестабильно из-за лавинообразного роста потребления оперативной памяти. Процесс rphost постепенно захватывает доступные ресурсы, доводя утилизацию ОЗУ до 90–98%, после чего сервер уходит в глубокий своп, сессии пользователей зависают (быстро высвободить ресурсы поможет обработка принудительного завершения спящих и зависших сеансов 1С), а единственным выходом становится жесткая перезагрузка всей системы. Особенно остро эта проблема проявилась после изменения политики лицензирования фирмы «1С» в 2019 году, когда многие расширенные настройки управления процессами в лицензиях уровня ПРОФ были временно ограничены.
В этой статье мы подробно разберем, почему возникает данная проблема, как правильно настроить совместную работу сервера приложений 1С и СУБД MS SQL Server на одном физическом или виртуальном сервере, а также научимся диагностировать утечки памяти и локализовать неоптимальный код, приводящий к коллапсу системы.
Рассмотрим типовую архитектуру, когда сервер приложений 1С:Предприятие и СУБД MS SQL Server развернуты на одном физическом или виртуальном компьютере (в нашем примере сервер оснащен 96 Гб ОЗУ, а базы данных весят суммарно около 200 Гб). Если настройки обеих систем оставлены по умолчанию, неизбежно возникает конфликт за ресурсы:
rphost выполняют программный код конфигураций, формируют тяжелые отчеты, обрабатывают временные таблицы и сериализуют данные в XML/JSON. При обработке неоптимальных запросов или из-за системных утечек памяти в самой платформе процессы rphost начинают стремительно увеличивать свое адресное пространство.Для решения этой проблемы нам необходимо жестко разграничить ресурсы между СУБД и сервером 1С, а также настроить автоматические механизмы контроля и перезапуска рабочих процессов платформы.
Первое и самое простое правило при совместном размещении 1С и SQL на одном сервере — ограничить максимальный объем памяти, доступный СУБД. Это не позволит SQL Server забрать всю память у рабочих процессов 1С и операционной системы.
Проанализируем оптимальное распределение памяти для нашего сервера с 96 Гб ОЗУ:
rphost нормально дышать даже при пиковых нагрузках).Чтобы установить этот лимит в СУБД, выполним следующие действия:
44 * 1024 = 45056 МБ.После изменения лицензионной политики в версиях платформы 8.3.15 и выше фирма «1С» вернула возможность настройки перезапуска процессов по превышению памяти в лицензии уровня ПРОФ. Нам обязательно нужно воспользоваться этими параметрами, чтобы сервер 1С автоматически гасил «раздувшиеся» процессы rphost без участия администратора.
Откроем консоль администрирования кластера серверов 1С (удобнее управлять сессиями через обработку администрирования и управления сеансами кластера 1С) и перейдем в свойства нашего рабочего сервера (не кластера, а конкретного сервера в ветке «Рабочие серверы»). Настроим следующие параметры:
40 * 1024 * 1024 * 1024 = 42949672960 байт. Если установить значение в 0, платформа примет автоматический лимит в 80% от всей памяти сервера, что в нашем случае недопустимо.120 до 300 секунд. Это застрахует систему от случайных кратковременных всплесков потребления памяти при формировании тяжелых отчетов.48 * 1024 * 1024 * 1024 = 51539607552 байт.rphost превышает допустимый лимит памяти, кластер запускает новый, «чистый» процесс rphost, перенаправляя новые сессии пользователей туда. Старый процесс помечается как «выключенный», но он продолжает жить в памяти операционной системы, ожидая, пока активные пользователи завершат свои текущие вызовы. Параметр «Отключать выключенные процессы через» указывает время, по истечении которого старый процесс будет завершен принудительно. Критически важно установить этот параметр в ненулевое значение! Если оставить там 0, старые «раздутые» процессы так и останутся висеть в диспетчере задач ОС бесконечно. Рекомендуем установить значение от 180 до 600 секунд.Если в кластере активен всего один процесс rphost, то при превышении им лимита памяти под угрозой оказывается работа абсолютно всех пользователей. В момент перезапуска единственного процесса сервер может временно прекратить отклик, а пользователи заметят кратковременное подвисание системы.
Чтобы распределить нагрузку и сделать процедуру перезапуска незаметной, настроим использование нескольких рабочих процессов rphost в рамках одного сервера. Для 30 активных пользователей хорошей практикой будет создание 2 или 3 рабочих процессов (примерно по 10–15 пользователей на один процесс).
Настроить это можно в свойствах кластера 1С через консоль администрирования:
15. Как только число пользовательских и фоновых соединений превысит этот лимит, кластер автоматически запустит дополнительный процесс rphost для обслуживания новых подключений.Настройка лимитов памяти в SQL и 1С — это борьба с симптомами. Чтобы полностью победить проблему, нам необходимо найти и устранить причину утечки памяти. Чаще всего утечки вызваны ошибками программирования в кастомных доработках или неоптимальными тяжелыми запросами, которые поднимают в память сервера миллионы записей таблиц БД.
Рассмотрим по шагам методы поиска источников утечек памяти:
В моменты, когда потребление оперативной памяти начинает расти, откройте консоль администрирования 1С, перейдите в ветку Сеансы вашей информационной базы и добавьте в список колонок показатели Память (текущая), Память (пиковая) и Захвачено СУБД. Отсортируйте список по убыванию потребления памяти. Вы сразу увидите конкретного пользователя или фоновое задание, которое утилизирует львиную долю ресурсов. Обратите внимание на открытые у этого пользователя отчеты или запущенные обработки.
Технологический журнал — это самый мощный встроенный инструмент диагностики платформы 1С:Предприятие — для автоматизации этого процесса есть профессиональный инструмент анализа производительности и технологического журнала 1С. С его помощью мы можем зафиксировать события выделения памяти и выявить участки кода, которые приводят к утечкам.
Для этого создадим в каталоге установки настроек платформы (по умолчанию для 64-битной версии это C:\Program Files\1cv8\conf) файл конфигурации с именем logcfg.xml. Добавим в него следующий XML-код для сбора событий MEM (мониторинг расхода памяти) и LEAKS (регистрация утечек памяти):
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<log location="C:\1C_Logs\MemoryLeaks" history="24">
<event>
<eq property="Name" value="MEM"/>
<gt property="Memory" value="104857600"/> <!-- Фиксируем события потребления более 100 Мб памяти -->
</event>
<event>
<eq property="Name" value="LEAKS"/>
</event>
<property name="all"/>
</log>
</config>
После создания файла перезапустите службу сервера 1С. В каталоге C:\1C_Logs\MemoryLeaks начнут формироваться текстовые файлы логов. Проанализировав логи событий LEAKS, вы сможете определить точные модули и строки кода 1С, в которых происходит утечка памяти (например, создание циклических ссылок между объектами, которые сборщик мусора платформы не может очистить самостоятельно).
Выяснить, какие таблицы базы данных занимают больше всего ресурсов, можно с помощью встроенных отчетов MS SQL Server — либо используя готовый инструмент анализа структуры и таблиц баз данных 1С. Нажмите правой кнопкой мыши на имя вашей базы данных в SSMS, выберите Отчеты (Reports) -> Стандартные отчеты (Standard Reports) -> Дисковое пространство, занимаемое таблицами (Disk Usage by Table).
Проанализируйте полученный список. Если в топе находятся таблицы временных файлов, версий объектов или логов (например, регистры сведений ВерсииОбъектов, ОчередьОперацийУзловИнформационныхБаз), возможно, требуется выполнить регламентные операции по очистке или свертке базы данных — в этом поможет готовая обработка для свертки и сжатия баз 1С.
Очень часто виновниками неконтролируемого роста процессов rphost и rmngr становятся фоновые механизмы платформы, которые работают в автоматическом режиме:
Не стоит забывать и о чисто платформенных багах. Релизы ветки 8.3.16 (включая указанную в обсуждении версию 8.3.16.1296) имели ряд зафиксированных ошибок, связанных с утечками памяти при работе с веб-сервисами, вызове внешних компонент и обработке XML.
Рекомендуется обновить платформу 1С до актуальных стабильных релизов (например, из веток 8.3.22 или 8.3.24, в зависимости от требований используемой вами конфигурации). При обновлении платформы обязательно выполните полную очистку серверного кэша:
1C:Enterprise 8.3 Server Agent).C:\Windows\ServiceProfiles\LocalService\AppData\Local\1C\1cv8).Для закрепления материала объединим наши действия в единый чеклист:
rphost в кластере, установив лимит по количеству соединений на один процесс.Применение этих комплексных мер позволит стабилизировать работу сервера, исключить непредвиденные зависания системы в течение рабочего дня и полностью отказаться от практики ежедневных или еженедельных вынужденных перезагрузок серверного оборудования.