Память SQL - просмотр реальной используемой памяти и доступной памяти

Question

Я провел некоторое исследование и нашел несколько разных способов выяснить, сколько памяти на самом деле использует SQL Server (поскольку диспетчер задач не точен, поскольку SQL зарезервирует столько памяти, сколько может для себя)

Я нашел эти два ресурса наиболее полезными:

Сколько оперативной памяти фактически использует SQL Server?

Как проанализировать результат 'dbcc memorystatus' в SQL Server 2008

Однако я испытываю затруднение из-за того, что когда я пробую оба метода на одном и том же сервере, у меня возникают проблемы с корреляцией чисел.

Я получаю очень разные результаты от счетчиков производительности (диспетчер памяти SQL - общая память сервера и память целевого сервера) по сравнению с запросом "dbcc memorystatus" VM Reserved и VM Committed.

Похоже, они оба указаны в «КБ», но цифры не близки. Может быть, я не смотрю на правильные результаты (может быть, зарезервированная / зафиксированная VM не является физическим чтением памяти и счетчик есть? Но тогда в этом случае, где в запросе SQL он показывает объем памяти, используемый SQL / резервирование, поскольку ни один из результатов не выглядит как числа, соответствующие счетчикам производительности)

Если кто-нибудь может дать мне какое-то руководство, учитывая, что я не очень опытен в мониторинге производительности SQL, я был бы очень признателен.

Заранее спасибо.

Answer 1

Просмотр счетчиков Perfmon для общей памяти сервера и памяти целевого сервера даст вам размер кэша пула буферов, который является подмножеством общего объема памяти, используемой SQL Server.Хотя обычно это самый большой пул памяти.Например, на моем сервере разработчика общий объем памяти сервера составляет 2759 МБ.Вы можете использовать следующий запрос для извлечения этого числа:

SELECT object_name, counter_name, cntr_value AS 'Total Server Memory (KB)'
FROM sys.dm_os_performance_counters 
WHERE counter_name = 'Total Server Memory (KB)'

DBCC MEMORYSTATUS, с другой стороны, отображает много информации.Если вы прокрутите примерно 3/4 пути вниз, вы увидите набор результатов со столбцами с именами «Буферный пул» и «Значение», причем первые буферные пулы будут называться «Committed» и «Target».Эти два значения перечислены как 8 КБ страниц, поэтому умножьте значение на 8192, чтобы получить результат в байтах, а затем разделите на 1048576, чтобы получить результат в МБ.На моем сервере разработчика у меня 353 230 страниц или 2759 МБ.

Первый набор результатов DBCC MEMORYSTATUS дает вам объем виртуальной памяти (ВМ), зарезервированной и зафиксированной SQL Server.Я бы проигнорировал Reserved, так как он не является хорошим индикатором того, сколько памяти фактически используется (это и есть значение Committed).Кроме того, Reserved немного выше, чем общая физическая память на всех моих серверах.Если у вас есть значение для «Locked Pages Allocated», то ваше значение «VM Committed», скорее всего, будет около 400 МБ - AWE и Locked Pages не учитываются при оплате фиксации, поэтому в диспетчере задач отображается неверное значение.

Вам не нужно слишком углубляться в DBCC MEMORYSTATUS, если у вас нет особых проблем с управлением памятью.Мои эмпирические правила заключаются в том, чтобы должным образом определить размер вашего буферного пула, иметь достаточно доступной физической памяти, чтобы избежать неиспользуемой памяти (~ 1-2 ГБ, но Windows всегда будет пытаться сохранить 128-256 МБ доступной физической памяти), и ваш «Пик»Commit Charge "(из диспетчера задач) никогда не превышает физический объем памяти на сервере.