← На главную

Разберем типичную и крайне неприятную ситуацию в администрировании серверов «1С:Предприятие»: после добавления оперативной памяти на физический сервер администратор снимает или значительно увеличивает лимиты потребления памяти в консоли кластера (например, задает допустимый объем памяти в 7 Гб или обнуляет его), однако рабочий процесс rphost при приближении к 3,5 Гб все равно аварийно завершается или перезапускается. Выясним причину такого поведения платформы и рассмотрим варианты решения проблемы.

Архитектурные ограничения 32-разрядного сервера 1С

Проанализируем техническую сторону вопроса. Главная причина кроется в разрядности установленного сервера платформы «1С:Предприятие». Исполняемый файл 32-битного рабочего процесса rphost.exe скомпилирован с поддержкой флага расширенного адресного пространства (Large Address Aware). В 64-битной операционной системе Windows такой процесс чисто теоретически способен адресовать не более 4 Гб виртуального адресного пространства.

Однако занять все 4 Гб под прикладные задачи процесс физически не может по следующим причинам:

1. Фрагментация адресного пространства: часть адресов непрерывно резервируется под системные библиотеки операционной системы, служебные стеки потоков и кучи (heaps) самого процесса.
2. Невозможность выделить непрерывный блок памяти: когда процессу требуется выделить новый блок данных, а непрерывного участка нужного размера в виртуальной памяти не находится из-за фрагментации, операционная система возвращает ошибку нехватки памяти (Out of memory).

На практике граница стабильной работы любого 32-битного процесса наступает в диапазоне от 3,2 до 3,6 Гб. После преодоления этой планки процесс неизбежно падает, даже если физической памяти на сервере установлено с огромным запасом.

Отсюда вытекает важный вывод: параметры кластера «Допустимый объем памяти» и «Интервал превышения допустимого объема памяти» лишь управляют внутренним мониторингом со стороны менеджера кластера rmngr. Если задать в свойствах кластера допустимый размер в 7 Гб или полностью обнулить значение, физические законы 32-разрядной адресации не изменятся: платформа просто перестанет заранее и мягко контролировать порог, а процесс продолжит аварийно падать по системной ошибке нехватки памяти.

Решение 1. Кардинальное решение — переход на 64-битный сервер 1С

Рассмотрим основной и самый надежный способ решения проблемы. Единственный путь, позволяющий процессу rphost беспрепятственно использовать 7 Гб, 16 Гб, 32 Гб и более оперативной памяти на один процесс, — это переход на 64-разрядную версию сервера «1С:Предприятие» (x86-64).

Разберем по шагам, что дает переход на платформу x64:

1. Снятие барьера в 4 Гб: 64-битный процесс может адресовать терабайты памяти, ограничиваясь только установленными в сервере физическими модулями RAM.
2. Устойчивость к тяжелым выборкам: объемные запросы, формирование тяжелых отчетов и групповые обработки перестают приводить к падению рабочего процесса из-за фрагментации памяти.
3. Простота администрирования: отпадает необходимость дробить кластер на множество мелких рабочих процессов ради обхода системного лимита.

Для перехода потребуется лицензия на сервер «1С:Предприятие (x86-64)», дистрибутив 64-битного сервера и переустановка службы кластера.

Решение 2. Оптимизация работы текущего 32-битного сервера

Если переход на 64-битную платформу временно невозможен, настроим кластер 1С так, чтобы суммарно задействовать всю оперативную память сервера без аварийных падений сеансов пользователей.

Посмотрим на логику работы: один 32-битный процесс rphost ограничен объемом ~3,5 Гб, но операционная система способна одновременно выполнять множество таких процессов. Два процесса смогут суммарно использовать около 7 Гб памяти, четыре процесса — до 14 Гб. Наша задача — заставить менеджер кластера распределять пользователей и базы между отдельными процессами.

Настроим свойства кластера и рабочего сервера по следующим шагам:

1. Настройка упреждающего перезапуска: вернем в свойствах кластера параметр «Допустимый объем памяти» и выставим безопасное значение ниже критического порога — от 2 500 000 000 до 3 000 000 000 байт (2,5–3 Гб). В связке с параметром «Интервал превышения допустимого объема памяти» кластер при достижении порога не уронит процесс с ошибкой, а запустит мягкий перезапуск: создаст параллельный новый rphost, направит новые подключения туда, а старый завершит только тогда, когда в нем закроются активные транзакции.
2. Ограничение числа соединений на процесс: укажем в свойствах рабочего сервера параметр «Количество соединений на один рабочий процесс» (например, от 10 до 25 соединений). При подключении новых пользователей менеджер кластера автоматически запустит второй, третий и последующие процессы rphost, распределяя общую нагрузку по памяти.
3. Изоляция баз: зададим параметр «Количество ИБ на один процесс», равный 1. В этом случае разные информационные базы перестанут делить память одного rphost, и интенсивная работа пользователей в одной базе не спровоцирует сбой в другой.
4. Регулярный перезапуск: включим параметр «Период перезапуска рабочих процессов» (например, 86400 секунд, что соответствует одному разу в сутки) для очистки фрагментированной памяти в нерабочие часы.

Анализ прикладных причин быстрого роста памяти

Проанализируем программный код, если процесс rphost набирает критические 3,5 Гб за считанные минуты. Быстрое исчерпание памяти в сеансах обычно провоцируют:

1. Запросы без порционной выборки: загрузка многомиллионных таблиц во временные структуры или выгрузка результата запроса целиком в объект ТаблицаЗначений на сервере.
2. Работа с объемными файлами: считывание больших бинарных файлов (PDF, архивов, изображений) непосредственно в оперативную память через объект ДвоичныеДанные вместо потоковой обработки на диске.
3. Кэширование структур: хранение крупных коллекций данных в переменных модуля управляемого приложения или сеансовых параметрах без своевременной очистки.

Таким образом, для ликвидации перезапусков процесса необходимо либо настроить кластер на распределение соединений по нескольким процессам rphost с упреждающим контролем памяти до 3 Гб, либо произвести миграцию на 64-разрядную версию платформы «1С:Предприятие».