Как ограничить потребление оперативной памяти SQL Server при совместной работе с сервером 1С:Предприятия?

При совместном размещении сервера СУБД MS SQL Server и Сервера 1С:Предприятия на одной физической машине системные администраторы часто сталкиваются с ситуацией, когда служба sqlservr.exe постепенно захватывает практически весь объем доступной оперативной памяти. В часы пиковой нагрузки свободная память исчерпывается до 99%, операционная система начинает активно использовать файл подкачки, а пользователи сталкиваются с резким падением производительности при проведении документов и формировании отчетов. Разберем по шагам, почему это происходит и как правильно настроить ограничения памяти на стороне SQL Server и кластера 1С.

Почему SQL Server захватывает всю память?

Проанализируем архитектуру управления памятью в СУБД. По умолчанию параметр максимального объема памяти сервера в MS SQL Server выставлен в значение 2 147 483 647 МБ (более 2 ПБ). Это означает, что сервер баз данных проектировался под принцип максимального кэширования: все прочитанные страницы данных, индексы и скомпилированные планы выполнения запросов удерживаются в буферном пуле (Buffer Pool) до тех пор, пока операционная система явно не запросит освобождение ресурсов.

Однако в версиях SQL Server 2005, 2008 и 2008 R2 параметр max server memory ограничивает только пул буферов для страниц размером до 8 КБ. Выделения памяти под большие планы запросов (Multi-Page Allocator), структуры потоков, процедуры и среда CLR могут приводить к дополнительному потреблению памяти свыше заданного лимита. Если не установить жесткие рамки, СУБД не оставит ресурсов для стабильной работы службы rphost сервера 1С и системных сервисов Windows.

Ограничение памяти через SQL Server Management Studio (SSMS)

Рассмотрим стандартный способ задания лимита ОЗУ для службы СУБД:

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

Для выполнения аналогичной операции через скрипт T-SQL используем системную процедуру sp_configure:

EXEC sys.sp_configure N'show advanced options', N'1';
RECONFIGURE WITH OVERRIDE;
EXEC sys.sp_configure N'max server memory (MB)', 5120;
RECONFIGURE WITH OVERRIDE;

Методика расчета оперативной памяти при совмещении ролей

Выясним, как правильно разделить доступную оперативную память между компонентами системы. При совмещении на одном сервере операционной системы, сервера 1С и MS SQL Server распределение планируется по следующим правилам:

1. Операционная система Windows Server: необходимо зарезервировать минимум 2–4 ГБ оперативной памяти для системных служб, драйверов и работы дискового кэша. Если сервер дополнительно выполняет роль терминального сервера (RDP), добавляем не менее 256–512 МБ на каждую активную пользовательскую сессию.
2. Сервер 1С:Предприятия: рабочим процессам rphost требуется от 2 до 4 ГБ и более. Точный объем зависит от числа активных пользователей, фоновых заданий и наличия ресурсоемких алгоритмов (например, обработка больших коллекций типа ТаблицаЗначений на стороне сервера).
3. SQL Server: получает весь оставшийся объем доступной оперативной памяти. Например, на сервере с общим объемом ОЗУ 8 ГБ оптимально выделить под SQL Server 4–5 ГБ (4096–5120 МБ), оставив 3–4 ГБ под нужды 1С и операционной системы. При 32 ГБ ОЗУ под нужды СУБД обычно выделяют 20–24 ГБ.

Экстренное освобождение памяти и сброс кэшей

Если SQL Server уже занял память, а производительность системы упала, не рекомендуется использовать аварийные bat-скрипты для перезапуска служб по расписанию. Перезагрузка службы MSSQLSERVER сбрасывает все кэши планов и страниц, из-за чего последующие запросы пользователей и перепроведение документов начинают выполняться в разы медленнее, вызывая высокую нагрузку на дисковую подсистему.

Для динамического сброса памяти без остановки работы пользователей можно временно уменьшить параметр max server memory на меньшее значение, выполнить RECONFIGURE, подождать несколько минут (пока служба отдаст освободившиеся страницы операционной системе), после чего вернуть расчетный порог обратно.

Для принудительной очистки кэшей планов и внутренних структур применяются команды DBCC:

-- Очистка кэша планов выполнения запросов (актуально при накоплении непараметризованных запросов 1С)
DBCC FREEPROCCACHE;

-- Очистка всех неиспользуемых системных кэшей
DBCC FREESYSTEMCACHE ('ALL');

Штатная настройка расхода памяти на стороне Сервера 1С

Чтобы избежать утечек памяти и падения рабочих процессов rphost, настроим встроенные механизмы управления ресурсами в консоли Администрирование серверов 1С:Предприятия в свойствах кластера или рабочего сервера:

1. Допустимый объем памяти: задает предел в байтах, который могут суммарно занимать рабочие процессы. При приближении к лимиту кластер плавно запускает новый процесс и завершает старый без аварийного разрыва сеансов пользователей.
2. Интервал превышения допустимого объема памяти: время в секундах, в течение которого процессу разрешается превышать указанный порог для завершения тяжелой операции.
3. Интервал перезапуска рабочих процессов: встроенный параметр периодического перезапуска процессов (например, 86400 секунд для перезапуска раз в сутки), который позволяет очищать фрагментированную память платформы в фоновом режиме без использования внешних костылей и скриптов.

Сбалансированное ограничение памяти max server memory для SQL Server в сочетании со штатными политиками перезапуска процессов rphost сервера 1С обеспечивает стабильную работу инфраструктуры без зависаний и внезапных перезагрузок служб.