Сколько памяти нужно моему SQL?
У меня есть виртуальная машина (сервер базы данных SQL), которая, как мне кажется, имеет больше памяти, чем ей нужно, однако я не уверен, до чего ее можно уменьшить, потому что я не понимаю, что именно «Используется», «Доступно», «Выполнено». »и« Кэшированная »память.
Ниже приведен снимок экрана диспетчера задач после того, как я провел некоторое нагрузочное тестирование. Предположим, что нагрузка не будет намного более интенсивной, чем эта.
Мне кажется очевидным, что 64 ГБ ОЗУ - это слишком много. Хотелось бы понять, сколько я могу убрать без снижения производительности.
Означает ли это, что мне нужно всего 8 ГБ, потому что это больше, чем «Используется»? Или мне нужно включить «кэшированную» сумму, когда я определяю, сколько нужно?
SQL Server будет удерживать память, которую он выделяет, поэтому, поскольку она не превышает 6-7 ГБ, я бы выделил 8 ГБ для SQL и оставил 2-4 ГБ дополнительно для ОС в этом случае (SQL всегда делает некоторые задачи вне памяти, для которой он выделяется sqlserver.exe.
Было бы неплохо поместить это значение (8 ГБ) в минимальные настройки памяти для вашего экземпляра sql-сервера. Таким образом, когда SQL требуется память, он не теряет времени на ее выделение первым, потому что при запуске он «занимает» 8 ГБ.
Играя с ОЗУ, вы всегда можете проверить ожидаемую продолжительность жизни страницы. Это покажет вам, как долго что-то остается в ОЗУ. Это значение в секундах, пока оно продолжает расти, вы золотой.
SELECT object_name, counter_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Buffer Manager%'
AND [counter_name] = 'Page life expectancy'
Пока он остается выше 300, все в порядке. Более низкие значения указывают на некоторую нехватку памяти. Это могло произойти после выполнения больших сортировок, обновления / перестроения индексов ... Не волнуйтесь, если это значение будет низким после перезапуска экземпляра, оно никогда не может быть больше, чем время выполнения SQL.
Второй интересный счетчик - это коэффициент попадания в буферный кэш, он покажет вам, сколько предыдущих запросов (за последние несколько секунд) было извлечено из памяти.
SELECT CAST(A.cntr_value1 AS NUMERIC) /
CAST(B.cntr_value2 AS NUMERIC)* 100 AS Buffer_Cache_Hit_Ratio_Percentage, A.cntr_value1 As Cache_Hits, B.cntr_value2 AS Cache_Lookups
FROM ( SELECT cntr_value AS cntr_value1
FROM sys.dm_os_performance_counters
WHERE object_name = 'MSSQL$SQL01:Buffer Manager' AND counter_name = 'Buffer cache hit ratio'
) AS A,
(SELECT cntr_value AS cntr_value2
FROM sys.dm_os_performance_counters
WHERE object_name = 'MSSQL$SQL01:Buffer Manager' AND counter_name = 'Buffer cache hit ratio base'
) AS B;
В этом примере мой экземпляр SQL - это именованный экземпляр SQL01, поэтому измените его на свое имя экземпляра или измените MSSQL$SQL01:Buffer Manager к MSSQLServer:Buffer Manager если у вас есть экземпляр по умолчанию.
Чем выше, тем лучше. В идеальной ситуации вы бы получили здесь 100%, это означает, что вся БД находится в памяти.
Отличные определения по ссылке ниже. Одна из стратегий - угадать первый ответ, а затем следить за ошибками страниц. По мере увеличения количества отказов страниц и уменьшения доступной памяти вы знаете, что вам необходимо увеличить объем памяти, доступной для виртуальной машины. VMware также должна позволять вам устанавливать, будет ли виртуальная машина ограничена указанным объемом памяти или ей разрешено переходить это ограничение в общий пул ресурсов.