В каком количестве памяти мой SQL нуждается?
У меня есть VM (сервер базы данных SQL), что я думаю, имеет больше памяти затем, этому нужно, однако я не уверен, что я могу уменьшить его до того, потому что я не понимаю точно, какую "Используемую", "Доступную", "Зафиксированную" и "Кэшируемую" память означают.
Следующее является снимком экрана Диспетчера задач после того, как я сделал некоторое тестирование загрузки. Давайте предположим, что загрузка не станет намного более интенсивной, чем это.
Для меня кажется очевидным, что 64 ГБ RAM слишком много. Я хотел бы понять, сколько я могу устранить, не уменьшая производительность.
Это означает, что мне только нужны 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, все в порядке. Ниже Значения будут указывать на некоторую нехватку памяти. Это может произойти после выполнения больших сортировок, обновления / восстановления индексов, ... Не волнуйтесь, если это значение будет низким после перезапуска экземпляра, оно никогда не может быть большим r, затем время выполнения 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 также должна позволять вам устанавливать, будет ли виртуальная машина ограничена указанным объемом памяти или разрешено переходить это ограничение в общий пул ресурсов.