Совмещение всех серверных ролей на одной физической или виртуальной машине — довольно распространенная, но крайне опасная практика в мире 1С. Когда на одном сервере под управлением одной операционной системы Windows Server одновременно работают СУБД MS SQL Server, сервер приложений 1С:Предприятия и сервер терминалов (RDP) на 100 пользователей, оперативная память становится самым дефицитным и критически важным ресурсом. Без жесткого контроля лимитов такая система обречена на постоянные зависания, взаимные блокировки и аварийные завершения процессов.
В этой статье мы подробно разберем, по каким принципам необходимо распределять оперативную память в подобных конфигурациях, произведем детальный математический расчет потребностей каждого компонента системы и пошагово настроим лимиты для предотвращения критических сбоев.
Рассмотрим конкретный кейс: база конфигурации 1С:Управление торговлей 11 объемом 65 ГБ, сотый пул активных пользователей, работающих в терминальном режиме (RDP), и всего 100 ГБ доступной оперативной памяти на сервере. Наша задача — распределить этот объем так, чтобы ни один из компонентов не вызвал сбой всей системы.
Проанализируем реальные аппетиты каждого участника системы:
rphost. В среднем рабочий процесс потребляет от 100 до 250 МБ на одного активного пользователя. Соответственно, под нужды сервера приложений необходимо выделить около 15–20 ГБ памяти. Отдавать серверу 1С больше половины ресурсов (например, 48 ГБ, как было у автора темы) не имеет практического смысла, за исключением случаев неоптимизированного кода, приводящего к масштабным утечкам памяти.Таким образом, оптимальная схема распределения 100 ГБ ОЗУ выглядит следующим образом:
По умолчанию MS SQL Server спроектирован так, чтобы забирать под свой кэш всю доступную физическую память, которую ему отдает операционная система. В совмещенной среде это приводит к тому, что при росте нагрузки SQL Server вытесняет память, необходимую для терминальных сессий пользователей или процессов 1С. Система начинает активно использовать файл подкачки (pagefile.sys) на диске, из-за чего быстродействие падает в десятки раз.
Для предотвращения этой ситуации необходимо жестко ограничить максимальный объем памяти СУБД. Настроим лимит через SQL Server Management Studio (SSMS):
45000 (что соответствует примерно 44 ГБ).Также эту операцию можно выполнить с помощью выполнения T-SQL скрипта в окне запросов:
EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'max server memory (MB)', N'45000'
GO
RECONFIGURE WITH OVERRIDE
GO
Когда на сервере возрастает нагрузка (например, несколько пользователей одновременно запустили построение тяжелых отчетов), операционная система Windows может принудительно забрать память у процесса SQL Server и отправить её кэш в своп на жестком диске. Это приводит к резким «зависаниям» 1С.
Чтобы запретить Windows сбрасывать кэш СУБД на диск, необходимо настроить политику «Блокировка страниц в памяти» (Lock Pages in Memory):
Win + R и введя команду gpedit.msc.NT Service\MSSQLSERVER).Поскольку сервер приложений 1С и сервер СУБД SQL Server запущены в рамках одной операционной системы, им совершенно не обязательно общаться друг с другом через сетевой стек протокола TCP/IP. Использование локального протокола Shared Memory позволяет им обмениваться данными напрямую через выделенные области оперативной памяти, минуя сетевую карту и снижая нагрузку на процессор.
Проверим и включим протокол Shared Memory:
Сервер приложений 1С подвержен фрагментации памяти и утечкам из-за неоптимального кода конфигураций. Если запустить работу всех 100 пользователей в рамках одного рабочего процесса rphost, то при критической утечке памяти процесс аварийно завершится, выбросив всех пользователей из системы.
Разберем, как правильно настроить параметры кластера 1С через утилиту администрирования:
4194304 КБ (4 ГБ) на один процесс. Если процесс превысит этот лимит, сервер 1С начнет плавно перенаправлять новые сеансы на другие рабочие процессы, а старый процесс будет безопасно перезапущен после завершения активных задач пользователей.86400 секунд (24 часа). Автоматический перезапуск процессов раз в сутки (желательно ночью) помогает полностью очистить фрагментированную память.rphost. Это распределит нагрузку (примерно по 20-25 пользователей на процесс) и повысит общую отказоустойчивость системы.Для стабильной работы 1С на совмещенном сервере крайне важна правильная конфигурация параметров параллелизма и системных баз данных:
TempDB. Файлы этой базы данных должны быть размещены на самом быстром дисковом накопителе (NVMe/SSD). Количество файлов данных TempDB должно соответствовать количеству физических ядер процессора (но не более 8 файлов). Шаг авторасширения файлов необходимо задать фиксированным (например, 256 или 512 МБ), отказавшись от дефолтного расширения в процентах.Хотя вышеописанные настройки помогут стабилизировать работу совмещенного сервера, важно понимать: конфигурация «1С + SQL + RDP» на одной машине со 100 ГБ ОЗУ для 100 пользователей — это компромиссное решение, работающее на пределе возможностей оборудования.
Как упоминалось в процессе обсуждения на форуме, физический сервер автора имеет в распоряжении 250 ГБ оперативной памяти, на базе которой развернута система виртуализации. В такой ситуации правильным и надежным архитектурным решением будет разделение ролей по разным виртуальным машинам:
Разнесение RDP и серверов баз данных по разным виртуальным машинам гарантирует высочайшую отказоустойчивость, предсказуемость производительности и удобство администрирования всей корпоративной системы 1С.