Как устранить зависания rphost и ошибки нехватки памяти на сервере 1С

При совмещении на одной физической машине ролей терминального сервера (RDS), сервера приложений 1С:Предприятие и СУБД системные администраторы часто сталкиваются с критическими проблемами производительности. Процесс rphost начинает утилизировать 100% ресурсов процессора и оперативной памяти, пользователи получают сообщения «Ошибка при выполнении запроса POST», а переход на 32-разрядную версию сервера приводит к ошибке «Недостаточно объема памяти на сервере 1С:Предприятие».

Разберем детально причины возникновения этих проблем и пошагово настроим сервер для стабильной работы пользователей.

Анализ причин сбоев и узких мест архитектуры

Проанализируем типовую конфигурацию: около 15 информационных баз, суммарно порядка 30–45 активных пользователей, процессор уровня Core i7 и 16 ГБ оперативной памяти. В такой среде сбои возникают из-за одновременного действия нескольких факторов:

1. Превышение лимитов адресного пространства 32-битного сервера. Процесс rphost разрядности x86 жестко ограничен адресным пространством в 2 ГБ в ОС Windows. С учетом фрагментации памяти ошибка о ее нехватке наступает уже при потреблении 1.4–1.7 ГБ. Поэтому использование 32-разрядного сервера 1С при одновременной работе нескольких десятков пользователей неизбежно приводит к аварийным завершениям. Для продуктивных систем обязателен 64-разрядный сервер 1С.
2. Специфика ошибки POST-запроса. Ошибка выполнения POST-запроса на стороне тонкого клиента свидетельствует о разрыве транспортного соединения. Это происходит, когда рабочий процесс rphost аварийно падает из-за нехватки ОЗУ или наглухо зависает, выполняя тяжелый запрос. Также при размещении терминала, СУБД и 1С на одном хосте быстро исчерпывается пул динамических TCP-портов (состояние TIME_WAIT).
3. Конфликт за оперативную память. Каждый терминальный сеанс пользователя отнимает от 200 до 500 МБ памяти. Если параллельно работают файловые сеансы 1С, они также захватывают ОЗУ. При этом СУБД и кластер 1С остаются без необходимого кэша, что вызывает непрерывный сброс данных на диск и всплеск загрузки процессора.
4. Ограничения MS SQL Server Express. Бесплатная редакция СУБД может использовать не более 1410 МБ оперативной памяти для буферного пула одного экземпляра и не более 4 ядер процессора. Для 15 баз данных этого буфера критически мало: СУБД перегружает дисковую подсистему постоянным чтением с диска, из-за чего потоки 1С выстраиваются в очередь ожидания.

Ограничение оперативной памяти для СУБД MS SQL Server

Если используется редакция Standard или если требуется зафиксировать границы потребления ресурсов экземпляром MS SQL Server, настроим лимит памяти. Это защитит операционную систему и кластер 1С от ситуации, когда СУБД монополизирует всю свободную память.

1. Запустим среду SQL Server Management Studio (SSMS) и подключимся к целевому серверу баз данных.
2. В окне Обозреватель объектов (Object Explorer) нажмем правой кнопкой мыши на корневом узле сервера и откроем Свойства (Properties).
3. Перейдем на вкладку Память (Memory).
4. В поле Максимальный размер памяти сервера (в МБ) (Maximum server memory) укажем фиксированное значение. Рассчитаем его так: из общего объема физической памяти вычитаем объем, необходимый для ОС (минимум 4 ГБ), резервируем память под процессы rphost и сеансы пользователей, а остаток отдаем СУБД.
5. Нажмем ОК для применения настроек без перезапуска службы.

Оптимизация параметров кластера серверов 1С:Предприятие

Для предотвращения утечек памяти и изоляции сбойных сеансов настроим рабочие процессы кластера через консоль администрирования (Администрирование серверов 1С Предприятия):

1. Изоляция баз по рабочим процессам. В свойствах рабочего сервера укажем параметры Количество ИБ на один процесс (например, 1 или 2) и настроим допустимое Количество соединений на один процесс. Это распределит нагрузку между несколькими экземплярами rphost, и сбой в одной базе не парализует работу остальных.
2. Перезапуск процессов при утечках памяти. В свойствах кластера настроим параметры Допустимый объем памяти (в байтах) и Интервал превышения допустимого объема памяти (например, 30–60 секунд). Если рабочий процесс превысит заданный порог, кластер плавно создаст новый процесс для обслуживания новых подключений, а проблемный перезапустит после завершения текущих транзакций.
3. Контроль тяжелых запросов. Параметр Безопасный расход памяти за один вызов позволяет прерывать выполнение отдельных некорректных отчетов пользователей, не допуская падения всего процесса rphost.

Разгрузка сервера и отказ от терминального режима

Совмещение терминального сервера и сервера приложений на 16 ГБ оперативной памяти — критически узкое место. Рассмотрим шаги по снижению нагрузки:

1. Исключение терминального доступа для локальных клиентов. Пользователи, находящиеся в одной локальной сети с сервером, должны подключаться через тонкий клиент 1С непосредственно со своих рабочих станций. Чтобы не устанавливать обновления вручную на каждом ПК, используем штатный механизм административной установки: дистрибутив новой платформы публикуется в общедоступной сетевой папке, а файл 1cestart.exe на клиентах автоматически обновляет версию.
2. Публикация баз на веб-сервере для удаленных пользователей. Для сотрудников из других филиалов и удаленных зданий не обязательно держать RDP-сессии. Опубликуем информационные базы на веб-сервере (IIS или Apache). Тонкий клиент 1С отлично функционирует по протоколу HTTP/HTTPS даже на медленных каналах связи, потребляя при этом в разы меньше трафика и ресурсов сервера, чем графическая сессия удаленного рабочего стола.
3. Полный перевод оставшихся баз в клиент-серверный режим. Нельзя допускать смешанной схемы, когда часть баз переведена на SQL, а часть работает в файловом режиме на том же диске. Файловые сеансы 1С создают неконтролируемую нагрузку на ОЗУ и дисковые очереди, замедляя работу сервера СУБД.
4. Настройка исключений антивируса. Добавим в постоянные исключения антивирусного монитора рабочий каталог кластера 1С (папка srvinfo), каталоги временных файлов, а также файлы баз данных .mdf и журналов транзакций .ldf.