Лимиты памяти 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)

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

31.08.2026    5448    Tantor    3    

17

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

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

11.08.2026    2831    jul.dolganova    9    

23

Администрирование СУБД Пароли Системный администратор 1С 8.3 1С:Розница 2 1С:Управление производственным предприятием Абонемент ($m)

Пароль пользователя СУБД лежит в 1CV8Clst.lst обратимо: кто читает папку srvinfo - достаёт пароли SQL всех баз кластера, минуя права 1С. Обработка показывает, у каких баз пароль извлекается, помечает слабые и выдаёт план защиты. К СУБД не подключается, ничего не пишет - только читает файл.

10 стартмани

06.08.2026    1564    16    nedomolkov.ivan    0    

7

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

Прогнал набор диагностических скриптов на двух рабочих базах: боевой с 580 сеансами и малонагруженной. Разбираю пять находок: статистика 97-дневной давности, 598 запросов со сканами, журнал транзакций в 73 % от данных, tempdb в один файл и 81 % ожиданий на параллелизме, который чинить не надо. Плюс три грабли, из-за которых самописный диагностический скрипт падает на чужом сервере. Семь рабочих скриптов внутри, копируются в SSMS как есть.

05.08.2026    2085    nedomolkov.ivan    8    

9

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

Журнал регистрации на нагруженной базе перестаёт открываться: файлы растут на гигабайты в день, просмотр виснет, история недоступна. Рассказываю, как мы вынесли журнал трёх продуктивных баз в ClickHouse: 35 млрд событий, поиск всех ошибок за сутки — 0,11 секунды, привычная форма журнала для пользователей и падение числа ошибок в проде в 23 раза за полгода. Архитектура, схема таблицы, грабли интеграции и все цифры с прода.

04.08.2026    2445    nedomolkov.ivan    0    

8

Администрирование СУБД 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

База 1С:ERP размером 646 Гб, полное маскирование за 5 часов - без создания промежуточной незащищенной копии. Разбираем бесплатный pg_anon на сквозном примере с реального продуктива.

27.07.2026    3659    Tantor    16    

16

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

Если вы работаете с 1С на PostgreSQL и жалуетесь на тормоза — скорее всего, дело в join predicate pushdown, которого в стандартном PostgreSQL нет. В MS SQL Server этот механизм работает «из коробки», и при миграции именно запросы к виртуальным таблицам 1С бьют по производительности сильнее всего. В этой статье — реальный кейс от Postgres Professional с разбором плана выполнения, ручным экспериментом и доработкой планировщика СУБД, которая ускорила запросы от 22 до 54 000 раз.

16.06.2026    10296    postgres_professional    13    

12

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

Вышел релиз СУБД Tantor Postgres 18, и мы хотим рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!

16.06.2026    4317    Tantor    7    

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

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

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

Про количество соединений на процесс подтверждаю, канонического значения в документации я тоже не нашёл. Смотрю в консоли кластера на конкретной сборке, других надёжных способов не знаю.
2. Ninel_S 32 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 32 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
Для отправки сообщения требуется регистрация/авторизация