Лимиты памяти rphost: когда кластер убьёт процесс сам, и чем ПРОФ отличается от КОРП

12.08.26

База данных - Администрирование СУБД

На infostart.ru вышел разбор Ивана Недомолкова «Сервер 1С падает: настройка сбора дампов (logcfg.xml), лимиты памяти и передача дампа в поддержку» - это хорошая инструкция, как ловить и разбирать падение rphost постфактум: logcfg.xml, procdump, анализ дампа. Но там нет ответа на вопрос «а почему кластер вообще прибил процесс сам, ещё до всякого краша». Мы дополняем разбор тремя сводными таблицами лимитов памяти и автомасштабирования кластера - и заодно фиксируем, чем в этой части лицензия ПРОФ урезана относительно КОРП.

Чёрный пояс платформы 1С. Лимиты памяти rphost: когда кластер убьёт процесс сам, и чем ПРОФ отличается от КОРП

Недавно вышел разбор Ивана Недомолкова «Сервер 1С падает: настройка сбора дампов (logcfg.xml), лимиты памяти и передача дампа в поддержку» - это хорошая инструкция, как отлавливать и разбираться с падениями rphost постфактум: logcfg.xml, procdump, анализ дампа. Но там нет ответа на вопрос «а почему кластер вообще уничтожил процесс сам, ещё до всякого краша». Мы дополняем разбор тремя сводными таблицами лимитов памяти и автомасштабирования кластера - и заодно фиксируем, чем в этой части лицензия ПРОФ урезана относительно КОРП.

 

1. Лимиты памяти и реакция кластера

Объём памяти рабочих процессов (rphost) и менеджеров кластера (rmngr) высчитывает сама платформа: в Windows - по показателю PagefileUsage (коммит), в Linux - как сумма vmSwap и vmRSS. На эти цифры завязаны три параметра свойств рабочего сервера в консоли администрирования кластера.

 

Параметр Значение по умолчанию Реакция кластера при превышении
Временно допустимый объём памяти процессов 0 - авторасчёт как 80% RAM сервера.
-1 отключает проверку.
Серверу перестают назначать новые соединения. Отдельный параметр «Интервал превышения» по умолчанию равен 0 - то есть отложенный перезапуск выключен, пока администратор явно не задаст интервал (например, 300 с); после его истечения запускается мягкий последовательный перезапуск процессов, начиная с самого прожорливого.
Критический объём памяти процессов 0 - авторасчёт как 95% RAM сервера.
-1 отключает жёсткий лимит.
Процессы с наибольшим потреблением аварийно завершаются ОС и перезапускаются немедленно - без ожидания какого-либо интервала, ровно столько процессов, сколько нужно, чтобы вернуться в лимит.
Безопасный расход памяти за один вызов (только КОРП) 0 - авторасчёт как 5% от временно допустимого объёма памяти процессов.
-1 - любой вызов сверх временного лимита считается опасным.
Если в рамках одного серверного вызова процесс запрашивает память сверх расчётного предела, вызов немедленно прерывается исключением (событие EXCP в технологическом журнале).

 

2. Автомасштабирование rphost

Кластер может сам поднимать дополнительные процессы rphost, когда упирается в лимиты нагрузки на один процесс.

 

Параметр Значение по умолчанию Реакция кластера при превышении
Количество ИБ на процесс (только КОРП) 8. 0 снимает ограничение. Если рабочий процесс обслуживает больше ИБ, чем указано, кластер поднимает на этом сервере дополнительный rphost.
Количество соединений на процесс Зависит от версии платформы - единого «канонического» значения по умолчанию в документации не нашли, конкретную цифру для вашей сборки платформы проверяйте в консоли администрирования кластера (свойства рабочего сервера). При превышении активных соединений кластер запускает новый rphost для распределения нагрузки.
 
Осторожно с гипертрейдингом: при включённом Hyper-Threading логические ядра ОС не равны физическим - если считать лимиты «на глаз» по числу ядер в диспетчере задач, легко промахнуться мимо реальной ёмкости сервера.
 

3. Что реально урезано в лицензии ПРОФ

 

Часть этих же параметров кластера в лицензии ПРОФ не настраивается вообще, плюс два отдельных платформенных лимита - по ядрам и по сеансам.

Характеристика Лицензия ПРОФ Лицензия КОРП
Использование ядер процессора не более 12 физических/виртуальных ядер на компьютер кластера без ограничений
Максимальное число сеансов до 500 одновременных сеансов на одну информационную базу без ограничений
КОРП-функциональность на ПРОФ доступна в тестовом режиме, только пока с ИБ одновременно работает не более 10 сеансов; с 11-го сеанса функции КОРП блокируются доступна в полном объёме без ограничения по числу сеансов
«Безопасный расход памяти за один вызов» не поддерживается - параметр игнорируется платформой, даже если задан полностью настраивается
«Количество ИБ на процесс» не настраивается - всегда действует фиксированное значение 8 доступно для изменения

Лимиты по ядрам и сеансам применяются к серверу и к базе соответственно - организация с несколькими серверами кластера, на каждом из которых не больше 12 ядер, остаётся в рамках лицензии ПРОФ.

 

Что проверить у себя на кластере

  • Если у вас случаются частые падения rphost по нехватке памяти - сначала посмотрите фактические значения «Временно допустимого» и «Критического» объёма памяти в консоли администрирования, а не только диспетчер задач ОС: платформа считает по-своему (PagefileUsage / vmSwap+vmRSS), а не по «физической» занятой памяти.
  • Задан ли явно «Интервал превышения допустимого объёма памяти процессов» - по умолчанию он выключен, и мягкий предупреждающий перезапуск просто не сработает, пока вы его не включите.
  • На лицензии ПРОФ не тратьте время на настройку «Безопасного расхода памяти за один вызов» и «Количества ИБ на процесс» - платформа их всё равно не применит.

Вступайте в нашу телеграмм-группу Инфостарт

rphost logcfg.xml Аварийный дамп PrivateUsage WorkingSet procdump Временно допустимый объем памяти Критический объем памяти процессов Безопасный расход памяти за один вызов PagefileUsage vmSwap Лицензия уровня КОРП Лицензия уровня ПРОФ Событие EXCP Событие ATTN rmngr sqlncli11.dll MSOLEDBSQL Тип дампа Таймаут проверки соединений

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бухгалтерский учет Бесплатно (free)

После миграции с MS SQL на PostgreSQL закрытие месяца в 1С:ERP стало идти 8 часов вместо 12 минут. Рассказываем, как мы нашли причину в оценке Hash Join, которую планировщик завышал в миллионы раз, и как исправили её так, что проблемный запрос теперь выполняется за 18 секунд вместо часа.

19.10.2026    933    Tantor    0    

10

Администрирование СУБД HighLoad оптимизация Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны — какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.

01.10.2026    1430    Tantor    6    

17

HighLoad оптимизация Инструменты администратора БД Системный администратор Разработчик 1С 8.3 Абонемент ($m)

Найдите сеанс, занявший память rphost, и выведите процесс из работы тремя шагами через rac, не обрывая остальные сеансы. Прогнано на платформе 8.3.27.2130 (Windows) с серверной базой и фоновыми заданиями: в статье реальный вывод rac, замеры памяти и запись технологического журнала. Утилита на Python и скрипты в архиве. Linux не проверялся.

1 стартмани

30.09.2026    1161    Ninel_S    0    

2

DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)

В корпоративных инсталляциях «1С:Предприятие 8.3» под управлением PostgreSQL всё чаще проявляются архитектурные пределы масштабирования: рост числа пользователей, обязательная маркировка, плотный поток API-интеграций и высокая стоимость простоя. Вводная часть цикла разбирает ключевые факторы современной эксплуатационной нагрузки и формирует инженерную методологию эволюционной модернизации без остановки продуктивного контура. Материал основан на практическом кейсе «Торговый контур» и показывает, как определить целевые метрики (p95, MTTR, APDEX), выстроить наблюдаемость, стабилизировать работу кластера и подготовить инфраструктуру к дальнейшему масштабированию. Публикация задаёт фундамент для последующих частей, посвящённых телеметрии, оптимизации PostgreSQL, CI/CD и архитектурному росту.

1 стартмани

10.09.2026    1506    Ninel_S    0    

6

HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)

В рамках 18 релиза СУБД Tantor Postgres мы рассказывали об оптимизациях, которые помогают планировщику сделать более точный выбор между Nested Loop и Hash Join. В следующем релизе у нас планируются оптимизации, которые позволят ускорить выполнение как Nested Loop, так и Hash Join. Сегодня мы расскажем об одном из таких методов - фильтре Блума.

31.08.2026    6107    Tantor    3    

18

Администрирование СУБД Системный администратор Разработчик 1С 8.3 Бесплатно (free)

Мы подготовили для сообщества Infostart.ru практическое занятие, в котором каждый желающий сможет: научиться собирать реальные данные о процессах кластера 1С; выявлять «перестарков» — процессы старше периода и без соединений; выполнять безопасный перезапуск (с dry-run и подтверждением); настраивать автоматическую проверку через systemd на Linux; отправлять уведомления (Telegram, почта) при обнаружении проблем; работать с логами, ротацией, профилями кластеров и конфигурацией; развернуть полноценный учебный проект AdminClusterMonitor у себя в тестовой среде.

30.08.2026    1718    Ninel_S    2    

6

Администрирование СУБД Системный администратор Разработчик Бесплатно (free)

5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.

11.08.2026    3393    jul.dolganova    9    

24
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. nedomolkov.ivan 485 15.08.26 13:27 Сейчас в теме
Спасибо, что дописали, ссылку вашу под своей статьёй видел.

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

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

Про количество соединений на процесс подтверждаю, канонического значения в документации я тоже не нашёл. Смотрю в консоли кластера на конкретной сборке, других надёжных способов не знаю.
2. Ninel_S 214 16.08.26 23:04 Сейчас в теме
Коллега, Вы абсолютно правы и указываете на те же супер-грабли, на которые наступают практически все администраторы.

1. Про критический лимит и исчезающие дампы

Когда рабочий процесс превышает Критический объем памяти процессов, подсистема мониторинга кластера аварийно завершает его.

В этот момент стандартные правила создания дампов из logcfg.xml просто не успевают отработать, так как процесс убивается снаружи. В этом сценарии создание дампа регулируется исключительно свойством рабочего сервера «Записывать дамп процесса при превышении критического объема памяти». Если этот флаг в консоли не взведен — процесс будет тихо убит операционной системой по команде менеджера кластера. При этом в технологический журнал зафиксируется предупреждающее событие ATTN.

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

2. Про путаницу между Рабочим набором (Working Set) и Коммитом (PagefileUsage)

Это фундаментальная точка преткновения, которую мы обязаны отметить специально. Администраторы привыкли верить Диспетчеру задач Windows (показывающему физический Working Set), однако алгоритмы мониторинга 1С работают принципиально иначе:

Под Windows объем памяти процесса оценивается строго по значению PagefileUsage структуры PROCESS_MEMORY_COUNTERS. Это размер коммита (выделенной виртуальной памяти), который включает в себя страницы, уже вытесненные операционной системой в файл подкачки.

Под Linux же система честно суммирует показатели vmSwap (своп) и vmRSS (физический резидент).

Когда сервер загружен, ОС сбрасывает неактивные страницы rphost на диск. Физическое потребление процесса в Диспетчере задач падает (Working Set уменьшается), но показатель PagefileUsage (коммит) остается прежним. В итоге для платформы лимит уже превышен, и она инициирует перезапуск процессов, а удивленный администратор видит в Диспетчере задач свободную память и не понимает, почему сервер штормит.

3. Про каноническое количество соединений на процесс

Полностью с Вами согласна — золотого стандарта в документации нет, так как требования индивидуальны для каждой внедренной конфигурации и оборудования.

Однако, могу дополнить Ваше наблюдение важной деталью о поведении кластера. Платформа не просто распределяет пользователей, у нее есть встроенный механизм консолидации избыточных процессов. Если на сервере в течение 20 минут запущены два процесса rphost, суммарное количество соединений и баз на которых не превышает установленные лимиты, кластер пометит наименее загруженный процесс как устаревший. Новые соединения на него перестанут назначаться, а старым сеансам при первом же серверном вызове будет предложено мигрировать на активный процесс, после чего устаревший rphost будет корректно остановлен.
Прикрепленные файлы:
stability-guide-v2.pdf
3. shibudo 18.08.26 10:30 Сейчас в теме
(1)
Про количество соединений на процесс подтверждаю, канонического значения в документации я тоже не нашёл. Смотрю в консоли кластера на конкретной сборке, других надёжных способов не знаю


В современных версиях платформы (начиная с 8.3.15) значение по умолчанию — 256 соединений на процесс. Ранее этот параметр был равен 128 (в 2018 году я лично менял, помню :).

8.3.14
https://its.1c.ru/db/v8314doc#bookmark:cs:TI000000158
Количество соединений на процесс в тексте не указано, но на скриншоте в пункте "5.2.6.1. Добавление рабочего сервера в кластер" видно 128 соединений на процесс.

8.3.15
https://its.1c.ru/db/v8315doc#bookmark:cs:TI000000158
На скриншоте уже указано 256 соединений и в тексте указано значение по умолчанию:
Количество соединений на процесс
...
Значение по умолчанию равно 256 соединений на процесс.
4. Ninel_S 214 19.08.26 14:24 Сейчас в теме
(3)
(1)
Про количество соединений на процесс подтверждаю, канонического значения в документации я тоже не нашёл. Смотрю в консоли кластера на конкретной сборке, других надёжных способов не знаю


В современных версиях платформы (начиная с 8.3.15) значение по умолчанию — 256 соединений на процесс. Ранее этот параметр был равен 128 (в 2018 году я лично менял, помню :).

8.3.14
https://its.1c.ru/db/v8314doc#bookmark:cs:TI000000158
Количество соединений на процесс в тексте не указано, но на скриншоте в пункте "5.2.6.1. Добавление рабочего сервера в кластер" видно 128 соединений на процесс.

8.3.15
https://its.1c.ru/db/v8315doc#bookmark:cs:TI000000158
На скриншоте уже указано 256 соединений и в тексте указано значение по умолчанию:
Количество соединений на процесс
...
Значение по умолчанию равно 256 соединений на процесс.
Показать


Огромное спасибо, уважаемый Коллега, за этот красивый щелчок по носу и за точные ссылки! Благодаря Вашей внимательности очередная версия нашего PDF-руководства теперь технически безупречна и хранит этот исторический переход со 128 на 256 соединений для будущих поколений администраторов.
Искренне рада, что в нашей дискуссии участвуют люди, которые помнят платформу по скриншотам и лично подкручивали эти лимиты еще в 2018 году. Это было чертовски круто и красиво!
Прикрепленные файлы:
stability-guide-v3.pdf
5. magic1s 12 06.11.26 07:52 Сейчас в теме
Она (или он?) это все с помощью ии пишет, комменты тоже.
Для отправки сообщения требуется регистрация/авторизация