Каждый системный администратор и разработчик 1С рано или поздно сталкивается с ситуацией, когда серверное оборудование начинает работать на пределе своих возможностей из-за лавинообразного потребления оперативной памяти. Основными «виновниками» этого процесса традиционно выступают рабочий процесс сервера 1С (rphost) и процесс СУБД (например, sqlservr.exe).
В этой статье мы подробно и по шагам разберем, как локализовать утечку памяти, настроить кластер 1С для автоматического предотвращения подобных проблем, правильно сконфигурировать MS SQL Server и выявить проблемный программный код, который заставляет систему «съедать» все доступные ресурсы.
Когда оперативная память сервера практически исчерпана, первым делом необходимо понять, какой именно сеанс или база данных инициировали эту проблему. Давайте рассмотрим алгоритм оперативного поиска виновника:
htop в Linux) и перейдем на вкладку подробностей. Найдем процесс rphost, который потребляет аномальный объем памяти, и зафиксируем его идентификатор процесса (PID).Очень часто на практике встречается ситуация, когда пользователь запускает тяжелый отчет, понимает, что система зависла, и закрывает программу через Диспетчер задач на своем ПК. При этом на сервере 1С сессия остается активной, и запрос продолжает выполняться, продолжая неконтролируемо поглощать ОЗУ. Выявление таких «брошенных» сеансов — первоочередная задача администратора.
Если на сервере крутится несколько информационных баз, а рабочий процесс rphost всего один, локализовать проблему становится сложнее. К тому же падение или принудительное завершение этого процесса приведет к отключению абсолютно всех пользователей со всех баз.
Мы настоятельно рекомендуем настроить изоляцию информационных баз. Для этого выполним следующие действия в консоли кластера 1С:
rphost под каждую информационную базу (задается через требования назначения функциональности или свойства рабочих серверов в зависимости от версии платформы).Даже с учетом небольшого перерасхода памяти на запуск дополнительных процессов, мы получим колоссальное преимущество: каждая база будет работать в своем изолированном адресном пространстве. Если одна из баз начнет «течь», мы сможем безболезненно завершить конкретный процесс rphost, не затрагивая пользователей других баз данных.
Для борьбы с постепенной деградацией памяти (утечками, которые невозможно полностью устранить на уровне кода в силу специфики платформы или используемых внешних библиотек) существует проверенный административный инструмент — регламентный перезапуск процессов.
Давайте настроим автоматическую утилизацию процессов в свойствах нашего кластера:
86400 секунд (ровно одни сутки). Это заставит сервер 1С раз в день мягко обновлять рабочие процессы.rphost, перенаправляет новые сеансы на него, а старый процесс переводит в режим выключения. Как только все активные вызовы в старом процессе завершатся, он закроется автоматически.60 секунд. Если процесс превышает лимит дольше этого времени, кластер инициирует его мягкий перезапуск.Важно: Не стоит бояться этой настройки. Пользователи не заметят момента перехода на новый рабочий процесс, так как перенос соединений происходит в фоновом режиме на уровне кластера.
Если административные меры не помогают полностью решить проблему и память продолжает уходить слишком быстро, необходимо локализовать конкретную программную причину. Обычный Журнал регистрации 1С здесь не поможет — он фиксирует только бизнес-события. Нам понадобится Технологический журнал (ТЖ).
Давайте настроим файл конфигурации ТЖ logcfg.xml для сбора информации об утечках памяти. Нам потребуются события LEAKS, MEM и CALL.
Рассмотрим пример настройки файла конфигурации:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs" history="24">
<event>
<eq property="Name" value="LEAKS"/>
</event>
<event>
<eq property="Name" value="MEM"/>
</event>
<event>
<eq property="Name" value="CALL"/>
<gt property="Memory" value="104857600"/>
</event>
<property name="all"/>
</log>
<leaks collect="1"/>
</config>
Давайте разберем, за что отвечают эти параметры:
<leaks collect="1"/> активирует сбор информации о невыгруженных объектах платформы, для которых сборщик мусора не смог освободить память. В ТЖ запишется детальный стек вызовов, приведший к созданию этого объекта.MEM фиксирует динамику выделения памяти процессами 1С.CALL с фильтром по свойству Memory (в байтах) зафиксирует все серверные вызовы, которые оставили после себя более 100 МБ невыгруженной памяти в рамках одного обращения. Это позволит точно определить имя общего модуля и экспортного метода, где написан неоптимальный код.Чаще всего в прикладных решениях 1С память «течет» из-за нескольких классических ошибок разработчиков. Давайте проанализируем их:
rphost до его перезапуска. Избегайте перекрестных ссылок при проектировании сложных алгоритмов.МенеджерВременныхТаблиц внутри циклов или сложных процедур разработчики часто забывают очищать ресурсы. Временные таблицы хранятся в оперативной памяти сессии. Посмотрим на правильный пример работы:
МенеджерВТ = Новый МенеджерВременныхТаблиц;
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВТ;
// ... Выполнение запросов, создание временных таблиц ...
// Обязательное закрытие менеджера для освобождения оперативной памяти!
МенеджерВТ.Закрыть();
rphost может лавинообразно увеличивать потребление ОЗУ. Если функционал ПТП не критичен для пользователей, его рекомендуется отключить в настройках базы либо перенести регламентное задание по обновлению индекса на глубокую ночь.Неопределено сразу после завершения работы с ними.Поведение СУБД MS SQL Server по умолчанию спроектировано так, чтобы задействовать максимум доступных аппаратных ресурсов сервера. Если не ограничить аппетиты SQL Server, он постепенно заберет всю свободную память под свой буферный пул (кэш данных), лишив рабочий процесс 1С необходимого пространства для маневра. Это неизбежно приведет к си сильному замедлению работы всей системы и регулярному аварийному завершению процессов rphost.
Давайте выполним базовую настройку лимитов СУБД:
Применяя данные рекомендации в комплексе — изолируя базы данных, настраивая мягкий перезапуск рабочих процессов, ограничивая аппетиты СУБД и анализируя утечки через Технологический журнал — мы сможем обеспечить стабильную, быструю и бесперебойную работу всей системы 1С:Предприятие.