Память rphost: как мониторить лимиты кластера 1С
Память rphost — первое, что смотрят, когда сервер 1С начинает тормозить или перезапускать рабочие процессы. Считать её в процентах от RAM бессмысленно: кластер реагирует на свои лимиты, и алерт должен сравнивать память процесса именно с ними. Ниже — какие лимиты памяти есть у сервера 1С, в каких единицах их отдаёт rac и на какой ошибке мы сами получили алерт, который не мог сработать.
Какие лимиты памяти есть у кластера и сервера 1С?
У рабочего сервера несколько параметров памяти, и реагирует на них кластер по-разному.
Критический объём памяти процессов (в rac — critical-total-memory). Если все рабочие процессы сервера вместе заняли больше, процессы с наибольшим потреблением памяти останавливаются аварийно и запускаются заново. Пользователи этих процессов теряют сеансы.
Временно допустимый объём памяти процессов (temporary-allowed-total-memory) и интервал его превышения (temporary-allowed-total-memory-time-limit, в секундах). Пока объём превышен, на сервер перестают назначаться новые соединения. Если превышение длится дольше интервала, кластер перезапускает процессы с наибольшим потреблением — столько, чтобы остальные уложились в лимит.
Безопасный расход памяти за один вызов (safe-call-memory-limit). Вызов, который съел больше, прерывается с ошибкой «Превышен максимальный расход памяти сервера за один вызов», а рабочий процесс продолжает жить, и остальные пользователи этого не замечают.
Кроме них у сервера есть memory-limit и safe-working-processes-memory-limit, а у кластера — max-memory-size, предельный объём памяти одного рабочего процесса, и max-memory-time-limit, сколько секунд его можно превышать. Подробнее параметры описаны в руководстве администратора 1С:Предприятия, глава «Администрирование».
Ноль в этих полях означает, что значение явно не задано. Таких кластеров много, и для мониторинга это важно: сравнивать память процесса не с чем.
В каких единицах rac отдаёт память: байты или килобайты?
Здесь и кроется ловушка. Утилита rac показывает поля памяти в разных единицах, и в выводе это никак не помечено — просто числа.
В килобайтах: memory-limit сервера, max-memory-size кластера, а также memory-size и selection-size процессов из rac process list.
В байтах: safe-working-processes-memory-limit, safe-call-memory-limit, critical-total-memory и temporary-allowed-total-memory.
Проверить это можно в справке самой утилиты: rac help server и rac help cluster показывают у каждого параметра заполнитель единицы — Kb или bytes. Если вы пишете свой сборщик или шаблон для Zabbix, сверяйтесь со справкой своей версии платформы, а не с соседним полем.
Хорошее правило из соглашений об именах метрик Prometheus: переводить всё в базовые единицы при сборе и писать единицу в имени метрики (onec_process_memory_bytes). Тогда ошибка остаётся в одном месте — в сборщике, — а не в каждом правиле и дашборде.
Как мы получили алерт, который не мог сработать
Наш сборщик 1С читал лимиты через rac и умножал на 1024 все поля памяти сервера, считая их килобайтами. Для memory-limit это верно, для critical-total-memory — нет.
На стенде с 1С 8.3.27 критический объём памяти 4 ГиБ (4294967296 байт) превращался в метрике в 4 ТиБ. Процесс rphost на 386 МБ давал 0,009 % лимита вместо 9 %. Правило «память rphost больше 70 % лимита» не могло сработать никогда: чтобы дойти до порога, процессу понадобились бы терабайты.
Самое неприятное в таких ошибках — они тихие. Сбор успешен, метрика есть, дашборд рисует ровную линию у нуля, алерт в состоянии «норма». Всё выглядит как здоровый сервер.
Исправление — единица своя у каждого поля, перевод в байты сразу при сборе и тест, который прогоняет сборщик на реальном выводе rac со стенда и сверяет каждое значение. Попутно нашлась вторая особенность: на 8.3.27 команда rac server update с safe-working-processes-memory-limit завершалась с кодом 0, но rac server info после неё по-прежнему показывал ноль. Лимит пришлось задавать через critical-total-memory. Поэтому после любой правки лимитов перечитывайте их через server info, а не верьте коду возврата.
Как считать память rphost к лимиту
Память процесса — memory-size из rac process list (килобайты, умножаем на 1024). Лимит для процесса удобно брать по первому заданному значению: safe-working-processes-memory-limit, затем critical-total-memory, затем max-memory-size кластера, всё уже в байтах. Если ни один не задан, метрику лимита не публикуем вовсе — тогда правило молчит честно, а не считает процент от выдуманного числа.
Выражение для правила в стиле PromQL выглядит так: 100 * max by(host,pid)(onec_process_memory_bytes) / on(host) group_left() max by(host)(onec_process_memory_limit_bytes). Пороги, от которых мы отталкиваемся, — 70 % «внимание» и 90 % «критично» с задержкой 5 минут и гистерезисом, чтобы алерт не мигал на границе. Остальные пороги по кластеру 1С разобраны в статье о том, при каких значениях 1С действительно тормозит.
Рядом с процентом стоит держать абсолютную память rphost и перезапуски процессов. Кластер, который регулярно сам снимает rphost по лимиту, — повод разбираться с утечкой или тяжёлыми вызовами, даже если алерт по памяти ни разу не горел. На этом построен мониторинг 1С у нас: память, лимиты и события кластера на одном дашборде.
Что проверить у себя
— Выполните rac cluster list, затем rac server list --cluster=ID и rac cluster info --cluster=ID, где ID — идентификатор кластера из первой команды: какие лимиты памяти реально заданы, а где ноль.
— Сравните лимит в мониторинге с выводом rac. Если critical-total-memory равен 4294967296, а в метрике 4398046511104 — лишний множитель 1024.
— Сверьте память процесса: memory-size из rac process list, умноженный на 1024, с RSS из ps -C rphost -o pid,rss на Linux или WorkingSet64 из Get-Process rphost на Windows. Совпадать точно они не обязаны, но порядок должен быть один.
— Посчитайте вручную текущий процент памяти самого большого rphost и сравните с тем, что показывает правило.
— Проверьте, что правило способно сработать: временно понизьте порог алерта (не лимит кластера!) ниже текущего значения и дождитесь уведомления в канал дежурных.
— Отдельно отслеживайте кластеры, где лимит не задан: там правило по памяти молчит, и это нужно знать, а не обнаружить в день аварии.
— Если у кластера есть администратор, убедитесь, что сборщик авторизуется: ошибка авторизации rac тоже выглядит как «данных нет, алертов нет».
Частые вопросы
Почему не считать память rphost в процентах от RAM?
Кластер ничего не делает при 90 % RAM — он снимает процессы по своим лимитам. Алерт от RAM срабатывает то слишком рано на сервере с запасом памяти, то слишком поздно, когда кластер уже перезапустил rphost. Процент от RAM полезен для сервера в целом, а для rphost нужен процент от лимита кластера.
Что будет, если превышен критический объём памяти процессов?
Кластер аварийно останавливает процессы с наибольшим потреблением памяти и запускает их заново. Сеансы пользователей на этих процессах прерываются с ошибкой. Поэтому алерт «внимание» должен приходить заранее, на 70 % лимита, а не на 100 %.
Нужно ли задавать лимиты памяти, если на сервере много RAM?
Без лимитов один тяжёлый отчёт или утечка в rphost может занять всю память сервера, и страдают все базы на нём. Лимит на вызов и критический объём ограничивают ущерб одним вызовом или процессом. Значения подбирают по обычной рабочей памяти rphost: ниже неё процессы будут перезапускаться постоянно.
Как это сделано в Voltir
Агент раз в минуту читает лимиты кластера и сервера через штатный RAS, переводит каждое поле в байты по его единице и считает память rphost к лимиту; если лимит в кластере не задан, правило молчит. Как подключить сбор, описано в документации по мониторингу 1С, пороги и гистерезис настраиваются в разделе об алертах. Дашборд с памятью rphost, лимитами и событиями кластера можно открыть в живом демо.
Если нужен не только мониторинг, но и дежурство по алертам, есть мониторинг как услуга; стоимость — на странице тарифов.