Почему MS SQL Server и сервер 1С не занимают оперативную память и как правильно диагностировать потребление ОЗУ?

Рассмотрим ситуационную задачу, когда при работе сервера 1С:Предприятие и MS SQL Server в Диспетчере задач отображается минимальное потребление оперативной памяти процессом sqlservr.exe (например, порядка 150 МБ), несмотря на наличие активных пользовательских сеансов и настроенные лимиты. При этом пользователи могут сталкиваться с задержками при проведении документов, открытии списков и формировании отчетов.

Выясним причину такого поведения системы. В большинстве случаев происходит путаница между показателями Рабочий набор (Working Set) и реально зарезервированным объемом памяти Выделенная память (Commit Size) в операционной системе Windows.

Основные причины низких показателей памяти в Диспетчере задач

Проанализируем, почему Диспетчер задач может показывать невысокое использование физической памяти СУБД при активной работе баз 1С:

1. Использование механизма Lock Pages in Memory (LPIM): Если для учетной записи службы MS SQL Server включена локальная политика Блокировка страниц в памяти, СУБД выделяет оперативную память через специальный API (Address Windowing Extensions / Large Pages). Выделенная память исключается из виртуального рабочего набора Windows и переходит в заблокированные страницы, из-за чего колонка «Рабочий набор» в Диспетчере задач показывает лишь единицы или сотни мегабайт, тогда как СУБД фактически использует несколько гигабайт.
2. Сжатие рабочего набора операционной системой (Working Set Trimming): Когда на одном физическом сервере запущены Windows Server, кластер 1С (процессы rphost, rmngr, ragent) и MS SQL Server, при возникновении дефицита ОЗУ операционная система принудительно урезает рабочий набор процесса СУБД, сбрасывая кэш в файл подкачки. Это приводит к существенным подтормаживаниям 1С, так как СУБД вынуждена повторно читать блоки данных с диска.
3. Особенности заполнения буферного пула (Buffer Pool): Настройка min server memory в MS SQL Server не заставляет систему мгновенно резервировать весь объем ОЗУ при запуске службы. Заполнение кэша происходит динамически по мере выполнения тяжелых запросов и чтения страниц данных с диска.

Точная диагностика потребления памяти СУБД

Для получения объективных данных об использовании оперативной памяти разберем специализированные инструменты мониторинга.

Во-первых, откроем Монитор ресурсов (Resource Monitor) на вкладке «Память» и проверим значение в колонке Завершено (KB) / Commit Size для процесса sqlservr.exe. Этот показатель отражает суммарный объем физической памяти и файла подкачки, зарезервированный СУБД.

Во-вторых, обратимся к внутренним командам и динамическим административным представлениям (DMV) MS SQL Server.

Для экспресс-анализа структуры выделенной памяти выполним команду в SQL Server Management Studio:

DBCC MEMORYSTATUS;

Для получения детальных сведений о физической памяти и механизме LPIM выполним следующий запрос к системному представлению sys.dm_os_process_memory:

SELECT 
    physical_memory_in_use_kb / 1024 AS PhysicalMemoryMB,
    locked_page_allocations_kb / 1024 AS LockedPagesMB,
    process_physical_memory_low AS IsMemoryLow
FROM sys.dm_os_process_memory;

Проанализируем значения ключевых полей этого запроса:

1. PhysicalMemoryMB — объем физической оперативной памяти, фактически используемый процессом СУБД.
2. LockedPagesMB — объем памяти, выделенный с использованием заблокированных страниц (LPIM).
3. IsMemoryLow — флаг (0 или 1), указывающий, отправляет ли Windows сигнал СУБД о критической нехватке памяти в системе.

Рекомендации по настройке совместной работы 1С и MS SQL Server

Рассмотрим пошагово комплекс мер по правильному распределению ресурсов и предотвращению падения производительности:

1. Ограничение максимальной памяти СУБД: При совместном размещении 1С и СУБД на одном сервере (например, с 16 ГБ ОЗУ) необходимо явно задать верхний лимит для SQL Server через параметр max server memory (установив значение в районе 6–8 ГБ). Это оставит необходимый резерв для процессов 1С (rphost) и самой ОС Windows.
2. Включение политики Lock Pages in Memory: В оснастке secpol.msc (Параметры безопасности -> Локальные политики -> Назначение прав пользователя) предоставим учетной записи службы SQL Server право Блокировка страниц в памяти. Это защитит кэш СУБД от выгрузки в файл подкачки при всплесках нагрузки со стороны процессов 1С.
3. Оптимизация однократных запросов: В настройках сервера СУБД включим параметр optimize for ad-hoc workloads в значение 1. Это позволит экономить память буферного пула, не сохраняя полные планы выполнения для редких или однократных динамических запросов 1С.
4. Предоставление права выполнения задач по обслуживанию томов: Добавим учетной записи SQL Server право Выполнение задач по обслуживанию томов (Perform Volume Maintenance Tasks) в secpol.msc для включения мгновенной инициализации файлов баз данных при их автоматическом расширении.