Цена SafeMemoryUsageBufferPercent: что платим на самом деле

• Область: буфер безопасного использования памяти кластера, лимит рабочего процесса rphost, порог принудительного завершения и связанные флаги менеджера кластера rmngr.
• Платформы: сервер 1С:Предприятие 8.3, кластер на Linux или Windows, СУБД PostgreSQL или MS SQL в роли хранилища прикладных данных.
• Инструменты: консоль администрирования кластера rac, утилита ragent, журнал технологического журнала и счётчики ОС по RSS рабочих процессов.
• Не рассматривается: тонкая настройка СУБД, сетевые балансировщики перед веб-серверами, лицензирование и состав конфигурации прикладного решения.

Резерв топлива в баке не увеличивает скорость автомобиля, но определяет, успеете ли вы доехать до заправки без остановки на обочине; в кластере 1С роль такого резерва играет процент памяти, который rmngr удерживает «под страховку» перед тем, как начать отключать сеансы и перезапускать rphost.

На практике спор идёт не о том, нужен ли лимит памяти у рабочего процесса, а о том, насколько рано менеджер кластера считает память исчерпанной. Симптом типичен: интерактивные пользователи жалуются на «вылет в окно авторизации» без текста ошибки в журнале регистрации, а на сервере в тот же интервал фиксируют завершение rphost с кодом, похожим на штатное закрытие процесса. Связь с настройками кластера часто остаётся незамеченной, потому что мониторинг смотрит только средний RSS за сутки, а решение принимается по пиковому потреблению в окне отчёта или обмена с внешней WMS-системой.

Ниже зафиксированы параметры, которые задают цену выбранного резерва: сколько памяти вы сознательно не отдаёте под кэш платформы и сколько сеансов готовы потерять при одновременном пике нескольких информационных баз на одном хосте.

Параметры

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

Чек-лист внедрения

1. Зафиксируйте суммарную RAM хоста и текущий RSS всех rphost в час пик (например, 08:30-09:00 и 17:45-18:30 для базы «СкладскаяЛогистика»).
2. Вычислите рабочий потолок: RAM минус резерв ОС и СУБД на том же сервере минус SafeMemoryUsageBufferPercent; запишите число в мегабайтах в паспорт сервера.
3. Разделите потолок на планируемое число rphost; полученное значение сравните с MemoryLimit каждого процесса в консоли кластера.
4. Если MemoryLimit равен 0, установите лимит не выше расчётного потолка на процесс, но не ниже пикового RSS типового rphost плюс 15 % для кэша.
5. Подберите MemoryExcessTime: для интерактива оставьте не менее 300 секунд, для хоста с тяжёлыми регламентными отчётами увеличьте до 600-900 секунд при мониторинге пиков.
6. Согласуйте RestartSchedule с окном обмена: плановый перезапуск не должен попадать на регламент «ВыгрузкаОстатковНаТСД» и аналогичные задания без общего таймаута.
7. После изменения SafeMemoryUsageBufferPercent перезапустите только rmngr в согласованное окно; проверьте, что rphost поднялись с новыми лимитами.
8. Включите выборку технологического журнала по событиям EXCP и PROC с отбором по процессу rphost на 48 часов после изменений.

Имена параметров в консоли администрирования отображаются на русском языке; при автоматизации через rac используйте английские ключи из справки утилиты для того же кластера.

Ограничения

SafeMemoryUsageBufferPercent применяется к памяти всего сервера, а не к сумме MemoryLimit процессов; при завышенном буфере rmngr раньше инициирует освобождение памяти, даже если каждый rphost формально ниже своего лимита.

MemoryLimit измеряется по учёту платформы 1С, а не по Task Manager или htop; расхождение с RSS в 10-25 % на холодном старте считается нормальным, на прогретом процессе после суточной работы разрыв может быть меньше.

При одном rphost на хосте завершение процесса по памяти равносильно обрыву всех сеансов информационной баз, привязанных к этому процессу; резерв второго rphost на том же сервере увеличивает расход RAM, но снижает вероятность одновременного простоя всех пользователей.

Лимит 0 на MemoryLimit отключает только явный потолок в настройках; rmngr всё равно реагирует на нехватку физической памяти с учётом буфера, поэтому «без лимита» не означает «без перезапусков».

Изменение LoadBalancingMode не перераспределяет уже открытые сеансы; эффект виден на новых подключениях после следующего входа пользователя или перепубликации сеанса.

MinProcesses больше нуля удерживает пустые rphost в памяти: это ускоряет приём новых сеансов, но уменьшает запас до срабатывания SafeMemoryUsageBufferPercent на сервере с 32 ГБ RAM и двумя постоянными процессами по 1,2 ГБ базового RSS.

Увеличение MemoryLimit без добавления физической RAM или без снижения буфера переносит проблему на уровень ОС: начинается paging, растёт время отклика всех баз на узле, хотя формально ни один rphost не достиг своего потолка.

Зависимости

Количество rphost на узле связано с параметрами кластера «Максимальное количество рабочих процессов» и «Минимальное количество рабочих процессов»; при автоматическом добавлении процессов rmngr создаёт новый rphost, если текущие упираются в MemoryLimit или в правила распределения нагрузки.

Размещение rmngr и ragent на том же хосте, что и все rphost, уменьшает сетевую задержку управления, но добавляет конкуренцию за RAM с буфером SafeMemoryUsageBufferPercent; вынос rmngr на отдельный узел не снимает лимит памяти с rphost прикладного сервера.

Тяжёлые фоновые задания конфигурации «ПроизводствоМебели» и регламентные операции СУБД на том же диске увеличивают время реакции rphost при срабатывании лимита; симптом маскируется под «зависание формы», хотя процесс уже в фазе завершения.

Параметры сеанса «Блокировка начала сеанса» и «Количество соединений на процесс» ограничивают плотность пользователей на одном rphost независимо от MemoryLimit; узкий MemoryLimit при высоком числе соединений даёт частые мелкие перезапуски вместо одного крупного.

Слой мониторинга ОС должен опираться на один и тот же интервал агрегации, что и решения rmngr; сравнение «минутного» RSS с «секундным» порогом MemoryExcessTime даёт ложные выводы при разборе инцидентов.

Связка «кластер + несколько информационных баз на одном rphost» повышает цену ошибки: база «ЗарплатаЦехA» и база «СкладскаяЛогистика» делят один MemoryLimit, и пик отчёта по складу может завершить процесс с активными бухгалтерскими сеансами.

Таймаут неактивности сеанса и параметр «Время засыпания пассивного сеанса» не освобождают память мгновенно; до удаления сеанса rphost продолжает удерживать кэш метаданных, и лимит срабатывает раньше, чем ожидает администратор по числу «спящих» пользователей в консоли.

Контроль

Ежедневно сверяйте максимальный RSS каждого rphost с установленным MemoryLimit и фиксируйте процент использования относительно расчётного потолка с учётом SafeMemoryUsageBufferPercent.

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

После каждого изменения буфера или лимита выполните контрольный сценарий: вход пятью сеансами в базу «ТестоваяНагрузка», запуск отчёта «ОборотыПоЯчейкам» с полным пересчётом, наблюдение за счётчиком памяти процесса в консоли кластера.

Алерт на хосте имеет смысл заводить по двум порогам: предупреждение при 85 % от доступной rmngr памяти и критический при записи о принудительном завершении rphost в системном журнале службы 1С.

Для Windows-сервера дублируйте контроль через счётчики производительности «Process\Working Set» по экземплярам rphost; для Linux сохраняйте снимки ps в тот же каталог, что и архив технологического журнала, с меткой времени изменения кластера.

При эскалации инцидента зафиксируйте в паспорте три числа: SafeMemoryUsageBufferPercent, MemoryLimit проблемного rphost и суммарный RSS всех rphost за 15 минут до обрыва; без этой триады повторное «увеличение RAM» часто не меняет поведение кластера.

Длинные команды администрирования вынесены в спойлер, чтобы не раздувать основной текст.

# Список кластеров на локальном ragent (порт по умолчанию 1540)
rac cluster list localhost:1540

# Параметры кластера: подставьте UUID из вывода list
rac cluster info --cluster=<cluster-uuid> localhost:1540

# Рабочие процессы и MemoryLimit
rac process list --cluster=<cluster-uuid> localhost:1540
rac process info --cluster=<cluster-uuid> --process=<process-uuid> localhost:1540

# Изменение SafeMemoryUsageBufferPercent (пример значения 25)
rac cluster update --cluster=<cluster-uuid> \
  --safe-memory-usage-buffer-percent=25 localhost:1540

# Изменение MemoryLimit для процесса (пример 8192 МБ)
rac process update --cluster=<cluster-uuid> --process=<process-uuid> \
  --memory-limit=8192 localhost:1540

# Фрагмент ragent.cfg (Linux, каталог установки сервера 1С)
# Порт агента по умолчанию: 1540
# Имя кластера задаётся при создании, не путать с именем ИБ

[ClusterParameters]
# Дублирование части настроек возможно через консоль; при расхождении
# приоритет у параметров, применённых через rac к работающему rmngr.

Утилиты

# RSS всех rphost на Linux (пример)
ps -C rphost -o pid=,rss=,cmd= | awk '{printf "PID=%s RSS_KB=%s\n", $1, $2}'

# Суммарный RSS rphost в мегабайтах
ps -C rphost -o rss= | awk '{s+=$1} END {printf "SUM_RSS_MB=%.0f\n", s/1024}'

# Доступная память и буфер (подставьте свой PROCENT вместо 20)
free -m | awk '/Mem:/ {printf "TOTAL_MB=%s AVAIL_MB=%s BUFFER20_MB=%.0f\n", $2, $7, $2*0.20}'

rac cluster list localhost:1540
rac cluster info --cluster=<cluster-uuid> localhost:1540
rac process list --cluster=<cluster-uuid> localhost:1540

# Windows: счётчик рабочего набора процессов rphost
# Get-Process rphost | Select-Object Id, @{N='WS_MB';E={[math]::Round($_.WS/1MB)}}