При работе связки 1С:Предприятие и MS SQL Server на виртуальных машинах (в частности, под управлением VMware) администраторы часто сталкиваются с парадоксальной ситуацией: серверу выделено достаточное количество оперативной памяти (например, 16 ГБ или 32 ГБ), но в Диспетчере задач Windows потребление процесса sqlservr.exe замирает на отметке в 100–200 МБ. При этом производительность системы крайне низкая, а тесты (например, тест Гилева) показывают неудовлетворительные результаты. В этой статье мы подробно разберем причины такого поведения и выясним, как заставить SQL Server работать на полную мощность.
Прежде всего, нам необходимо понять, действительно ли SQL Server не использует память, или мы имеем дело с особенностью отображения данных в Windows. Разберем механизм Lock Pages in Memory (Блокировка страниц в памяти). Когда эта политика включена, SQL Server использует специальные API-функции для выделения памяти, которые позволяют блокировать страницы в физической ОЗУ, предотвращая их сброс в файл подкачки (pagefile).
Важный нюанс: память, выделенная через этот механизм, не входит в так называемый "Working Set" (рабочий набор) процесса. Диспетчер задач Windows в колонке "Память" по умолчанию показывает именно Working Set. Таким образом, если SQL Server реально потребляет 10 ГБ через механизм Lock Pages, Диспетчер задач может продолжать показывать жалкие 150 МБ. Чтобы увидеть реальную картину, нам нужно использовать другие инструменты.
Проанализируем ситуацию с помощью запроса в SQL Server Management Studio (SSMS). Выполним следующий скрипт, чтобы узнать реальное распределение памяти:
SELECT
physical_memory_in_use_kb / 1024 AS Physical_Memory_Used_MB,
large_page_allocations_kb / 1024 AS Large_Pages_Used_MB,
locked_page_allocations_kb / 1024 AS Locked_Pages_Used_MB,
page_fault_count,
memory_utilization_percentage,
available_commit_limit_kb / 1024 AS Available_Commit_Limit_MB
FROM sys.dm_os_process_memory;
Если значение в колонке Locked_Pages_Used_MB значительно больше того, что показывает Диспетчер задач, значит, сервер успешно использует память, просто вы этого не видите в стандартном мониторе. Однако, если и здесь цифры малы, переходим к следующим шагам.
Рассмотрим ситуацию, когда настройка прав пользователя мешает корректной работе. Часто системные администраторы запускают службу SQL Server от имени системной учетной записи или локального пользователя, у которого нет прав на блокировку страниц.
Разберем по шагам, как проверить и настроить этот параметр:
gpedit.msc и нажмите Enter.MSSQLSERVER.Как показала практика обсуждения на форуме, одной из неочевидных причин низкой производительности и "пассивности" SQL Server являются режимы энергосбережения. Если физический сервер, на котором поднят гипервизор (VMware), работает в режиме Power Savings, процессоры могут снижать частоту, а шина памяти — замедляться. Это приводит к тому, что SQL Server не может быстро обрабатывать запросы и "лениво" запрашивает ресурсы у ОС.
Выясним, что нужно изменить:
Во-первых, на уровне физического сервера в настройках BIOS/UEFI необходимо выставить режим Static High Performance (или аналогичный, исключающий управление питанием со стороны ОС).
Во-вторых, внутри самой виртуальной машины Windows перейдите в Панель управления -> Электропитание и выберите план Высокая производительность (High Performance). Это критически важно для баз данных, так как исключает парковку ядер процессора и задержки при переключении состояний питания.
Проанализируем ситуацию со стороны гипервизора. У VMware есть механизм Memory Ballooning. Если физическому хосту не хватает памяти, он через специальный драйвер (vmmemctl) внутри виртуальной машины начинает "раздувать пузырь", заставляя гостевую ОС отдавать память. SQL Server, видя нехватку памяти в системе, моментально сжимает свой Buffer Pool.
Чтобы гарантировать стабильную работу SQL Server, выполним следующие настройки в VMware vSphere Client:
Это зарезервирует за виртуальной машиной весь объем выделенной ОЗУ на физическом уровне. Гипервизор больше не сможет забрать эту память через Ballooning, и SQL Server будет "чувствовать" себя гораздо увереннее.
Если настройки ОС и гипервизора проверены, но сомнения остаются, воспользуемся командой диагностики памяти внутри SQL. Выполните в Management Studio:
DBCC MEMORYSTATUS;
Этот отчет покажет детальную структуру распределения памяти. Посмотрим на раздел Memory Manager. Нас интересуют показатели Total Server Memory и Target Server Memory.
Если Total значительно меньше Target, это означает, что SQL Server хочет взять память, но ОС ему ее не дает. Если же оба значения малы, значит, проблема в настройках самого SQL Server — проверьте параметр Max Server Memory в свойствах сервера (вкладка Memory).
Подводя итог, можно сказать, что проблема "непотребления" памяти чаще всего является следствием совокупности факторов: визуального эффекта от политики Lock Pages in Memory и ограничений производительности со стороны железа или гипервизора.
Рассмотрим краткий чек-лист для исправления ситуации:
sys.dm_os_process_memory, а не через Диспетчер задач.Следуя этим шагам, вы обеспечите стабильную и быструю работу вашей системы 1С, а SQL Server начнет эффективно использовать все предоставленные ему ресурсы.