Как определить местоположение причины чрезмерной памяти в мс sql

Мы испытываем проблемы памяти с MS Sql 2008 R2. Кажется, существует утечка памяти, которая последовательно увеличивается в использовании памяти, пока это не добирается приблизительно до 1,5 ГБ и затем останавливается.

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

-- Note: querying sys.dm_os_buffer_descriptors
-- requires the VIEW_SERVER_STATE permission.

DECLARE @total_buffer INT;

SELECT @total_buffer = cntr_value
   FROM sys.dm_os_performance_counters 
   WHERE RTRIM([object_name]) LIKE '%Buffer Manager'
   AND counter_name = 'Total Pages';

;WITH src AS
(
   SELECT 
       database_id, db_buffer_pages = COUNT_BIG(*)
       FROM sys.dm_os_buffer_descriptors
       --WHERE database_id BETWEEN 5 AND 32766
       GROUP BY database_id
)
SELECT
   [db_name] = CASE [database_id] WHEN 32767 
       THEN 'Resource DB' 
       ELSE DB_NAME([database_id]) END,
   db_buffer_pages,
   db_buffer_MB = db_buffer_pages / 128,
   db_buffer_percent = CONVERT(DECIMAL(6,3), 
       db_buffer_pages * 100.0 / @total_buffer)
FROM src
ORDER BY db_buffer_MB DESC;
0
задан 23 July 2014 в 12:04
1 ответ

Если это выделенный модуль SQL Server, на котором не выполняется репликация, не запущен DTS/SSIS, и не запущен никакой другой процесс, который также нуждается в значительных частных байтах (на perfmon). msc's Process counters), в качестве начала, возьмите вашу общую физическую память в мегабайтах (запустите msinfo32.exe, если не уверены), умножьте это число на 0.8, округлите результат до целого числа, и в окне запроса запустите:

EXEC sp_configure 'max server memory (MB)', 'result'

где 'result' - это целое число, которое только что вычислено.

Убедитесь, что в учетной записи запуска SQL-сервера не справа (через gpedit.msc) указано "Lock pages In Memory".

Если есть другой процесс, требующий значительных частных байт, то вам необходимо еще больше уменьшить максимальное количество памяти сервера. Чем больше вы уменьшаете максимальное количество памяти сервера, тем меньше SQL сервер может использовать память для кэширования дискового ввода-вывода (и других потребностей в кэшировании), тем больше риск того, что SQL сервер станет медленнее, чем это считается приемлемым. Добавление большего объема памяти может быть приемлемым выбором (особенно учитывая стоимость 1,5 ГБ оперативной памяти).

После настройки максимального объема памяти сервера, используйте perfmon.msc для мониторинга счетчиков объекта Process для частных и виртуальных байтов, счетчика Avail MBytes объекта Memory, и счетчиков Target Server Менеджера Памяти Целевого Сервера и Total Server Memory. Используйте интервал опросов 5-15 секунд, и оставьте perfmon работать, пока проблема не будет решена, Как только она будет решена, остановите perfmon и проверьте ее результаты. При уменьшении объема памяти Avail MBytes до ~4-5 MB, SQL-сервер должен снизить объем памяти целевого сервера, при этом общая память сервера должна следовать за этой целью.

32-битный процесс (например, 32-битный SQL-сервер) не может обращаться к более чем 2 ГБ физической памяти, если только не используется AWE. 64-битный SQL-сервер может обращаться к большему объему памяти, чем вы можете себе позволить :).

Наконец, пожалуйста, предоставьте нам более подробную информацию о том, что понимается под "отказом сервиса". Что сообщает журнал ошибок SQL Server в момент сбоя? Что регистрирует системный журнал событий Windows в момент сбоя?

.
0
ответ дан 5 December 2019 в 13:39

Теги

Похожие вопросы