Как правильно настроить лимиты памяти процессов в кластере 1С:Предприятие 8.3 и обойти ограничения лицензирования?

Введение

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

Для борьбы с этим явлением в консоли администрирования кластера 1С предусмотрены специальные параметры рабочего сервера. В этой статье мы подробно разберем, как правильно рассчитать лимиты памяти, какой параметр должен быть больше, а также затронем важнейший исторический и практический аспект — разделение этих функций между лицензиями уровней ПРОФ и КОРП.

Критический и временно допустимый объем памяти: что должно быть больше?

При настройке свойств рабочего сервера в консоли администрирования кластера 1С нам доступны два ключевых параметра ограничения памяти:

1. Временно допустимый объем памяти процессов (измеряется в байтах).
2. Критический объем памяти процессов (измеряется в байтах).

Давайте ответим на главный вопрос: значение параметра «Критический объем памяти процессов» обязательно должно быть больше, чем значение «Временно допустимый объем памяти процессов» (при условии, что оба параметра настроены и их значения больше нуля).

Проанализируем детально, как работают эти механизмы изнутри, чтобы понять логику такого соотношения.

Механизм «мягкого» перезапуска: Временно допустимый объем памяти

Параметр Временно допустимый объем памяти процессов отвечает за запуск процедуры деликатного освобождения ресурсов без прерывания работы пользователей. Когда суммарный объем памяти, потребляемый рабочим процессом rphost, превышает установленный лимит, сервер 1С не убивает его мгновенно.

Вместо этого запускается следующий алгоритм:

1. Платформа фиксирует превышение лимита и запускает внутренний таймер. Длительность этого таймера определяется параметром «Предел превышения временно допустимого объема памяти процессов» (измеряется в секундах, по умолчанию обычно составляет от 60 до 300 секунд).
2. Если в течение этого времени нагрузка и потребление памяти не снизились естественным путем, процесс помечается системой как непроизводительный.
3. С этого момента новые сеансы пользователей больше не могут подключаться к данному процессу rphost — их запросы перенаправляются на другие, «чистые» рабочие процессы кластера.
4. Существующие активные пользователи продолжают работать в старом процессе до тех пор, пока не завершат свои текущие транзакции или вызовы. По мере их естественного выхода сеансы незаметно для пользователей мигрируют на новые процессы.
5. Как только все активные вызовы в проблемном процессе завершаются, старый rphost безопасно закрывается платформой, а вся занятая им память возвращается операционной системе.

Механизм «жесткого» спасения: Критический объем памяти

Параметр Критический объем памяти процессов — это экстренное средство предотвращения зависания и падения всего сервера из-за нехватки оперативной памяти (так называемый сценарий Out-Of-Memory).

Если один или несколько рабочих процессов rphost лавинообразно увеличивают потребление ОЗУ и достигают этой отметки, платформа 1С действует незамедлительно:

• Происходит мгновенная принудительная остановка (kill) процесса операционной системой.
• Никакие тайм-ауты на завершение сессий пользователей не выдерживаются.
• Пользователи, чьи активные сеансы находились на аварийно завершенном процессе, получают ошибку о разрыве соединения с сервером. Им приходится перезапускать клиентское приложение и заново вводить данные, которые не были сохранены в базу данных на момент сбоя.

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

Важный вывод: если вы установите критический объем памяти равным или меньшим, чем временно допустимый объем, то механизм мягкого перезапуска процессов просто никогда не успеет сработать. Сервер будет сразу «убивать» процессы при достижении нижнего порога, лишая пользователей возможности комфортно продолжить работу при плановом обновлении пула процессов.

Эволюция лицензирования: что произошло 10 сентября 2019 года?

В обсуждениях администраторов 1С часто фигурирует дата 10.09.2019. Это день, когда фирма «1С» ввела строгое программное разделение функционала технологической платформы в зависимости от используемых лицензий — уровня ПРОФ или КОРП.

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

Согласно первоначальным правилам лицензирования, для лицензий уровня ПРОФ планировалось полностью заблокировать возможность изменения параметров управления памятью рабочих процессов. Предполагалось, что эти настройки — прерогатива крупных корпоративных клиентов, использующих лицензии КОРП (которые требуются при наличии более 500 одновременно работающих сеансов или использовании более 12 ядер процессора на сервере).

Послабления для лицензий ПРОФ

Полный запрет на регулирование памяти для лицензий ПРОФ вызвал волну трудностей у средних и малых внедрений. Из-за утечек памяти серверы без настроенных ограничений регулярно зависали. Фирма «1С» оперативно отреагировала на отзывы сообщества и уже в октябре 2019 года выпустила официальное разъяснение и техническое послабление.

Для владельцев лицензий уровня ПРОФ была возвращена возможность легально настраивать и изменять три важнейших параметра кластера:

1. Критический объем памяти процессов
2. Временно допустимый объем памяти процессов
3. Предел превышения временно допустимого объема памяти процессов

Эти параметры на лицензиях ПРОФ теперь работают исключительно для целей перезапуска процессов (освобождения памяти). На лицензиях уровня КОРП они могут функционировать совместно с расширенными механизмами балансировки нагрузки и жесткими лимитами потребления ресурсов на один вызов сервера.

Практический пример расчета параметров памяти

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

• Общий объем оперативной памяти (RAM) сервера: 64 ГБ.
• На сервере крутится только служба 1C:Enterprise Server (СУБД вынесена на отдельный физический сервер, что является лучшей практикой).

Выполним расчет доступных лимитов:

1. Зарезервируем под нужды операционной системы и системных служб около 20% памяти (примерно 12 ГБ). Остается 52 ГБ свободной памяти для нужд процессов 1С.
2. Предположим, в кластере настроена работа 4 рабочих процессов rphost. Распределим доступную память между ними. На каждый процесс должно приходиться не более 13 ГБ в пике.
3. Рассчитаем Временно допустимый объем памяти процессов. Разумно установить его на уровне 70-80% от максимума для одного процесса. Пусть это будет 9 ГБ (9 663 676 416 байт).
4. Рассчитаем Критический объем памяти процессов. Установим его ближе к верхнему пределу физических возможностей — например, 12 ГБ (12 884 901 888 байт).
5. Установим Предел превышения временно допустимого объема памяти процессов равным 300 секунд (5 минут). Этого времени обычно достаточно для завершения тяжелых транзакций пользователей.

Для мониторинга потребления памяти процессами rphost силами операционной системы Windows можно использовать простой скрипт на PowerShell:

Get-Process rphost | Select-Object Id, ProcessName, @{Name="WorkingSet(MB)";Expression={[math]::round($_.WorkingSet / 1MB, 2)}} | Format-Table -AutoSize

Регулярно анализируйте показатели этого скрипта в периоды пиковой нагрузки. Если вы замечаете, что процессы постоянно завершаются аварийно, а пользователи жалуются на обрывы связи — плавно увеличивайте лимиты или оптимизируйте код конфигураций, закрывая утечки памяти.