11.4.8. Счетчики для анализа загрузки оперативной памяти

Анализ загрузки памяти средствами Системного монитора, счетчики Обмен страниц в сек (Pages/Sec), Buffer cache hit ratio (Процент попаданий в кэш буфера), Рабочее множество (Working Set), Ошибок страницы/сек (Page faults/sec), Доступно байт (Available baits), Total Server Memory (KB) (Общая память сервера (KB)), память AWE, параметр awe enabled

С точки зрения Microsoft, самая важная подсистема для баз данных OLTP (к которым относятся почти все используемые в повседневной работе базы данных) — это подсистема оперативной памяти. Более 90% запросов пользователей на чтение и запись обслуживается из буфера в оперативной памяти, без необходимости немедленного обращения к диску. Кроме того, нехватка памяти ведет к свопингу (активному обращению к файлу подкачки) и может привести к дополнительной нагрузке на процессорную и дисковую подсистемы.

Главный счетчик для анализа загрузки оперативной памяти с точки зрения операционной системы — это счетчик Обмен страниц в сек (Pages/sec) объекта Память (Memory). Физически этот счетчик показывает количество обращений в секунду к файлу подкачки (неважно, на чтение или запись). В курсах по SQL Server 6.5 и 7.0 пороговое значение этого счетчика определялось равным 5, в курсах по SQL Server 2000 — равным 10. В курсах и документации по SQL Server 2005 пороговое значение для этого счетчика вообще не определяется (пишут только о недопустимости его большого значения). Когда системе на самом деле не хватает оперативной памяти, значение этого счетчика измеряется сотнями, так что ошибиться здесь трудно. Отметим, что критична только информация, собранная за длительный промежуток времени — кратковременные скачки этого счетчика вполне допустимы.

Главный счетчик для определения того, хватает ли памяти самому SQL Server 2005, — счетчик Buffer cache hit ratio (Процент попаданий в кэш буфера) объекта Buffer Manager (Менеджер буфера) для данного экземпляра сервера. Он показывает, сколько запросов пользователей (в процентах к общему) обслуживаются из буфера без необходимости обращения к диску. Как уже говорилось ранее, рекомендуется, чтобы в течение длительного промежутка времени значение этого счетчика было не меньше 90%.

Для мониторинга подсистемы оперативной памяти можно использовать и другие счетчики:

q      если вы подозреваете, что в расходе памяти виноват не SQL Server 2005, а другое приложение, имеет смысл обратиться к объекту Процесс и посмотреть на значения счетчиков Рабочее множество (Working Set) и Ошибок страницы/сек (Page faults/sec). Первый счетчик показывает, сколько памяти в настоящий момент использует каждый конкретный процесс, второй — сколько раз для этого процесса пришлось обращаться к файлу подкачки. Значения этих счетчиков для объекта процесса SQL Server нужно сравнить с экземпляром _Total и другими процессами;

q      счетчик Доступно байт (Available baits) для объекта Память представляет объем физической памяти компьютера, которая свободна и может быть немедленно выделена какому-либо процессу. Значение этого счетчика в течение длительного промежутка времени не должно приближаться к 0;

q      счетчик Total Server Memory (KB) (Общая память сервера (KB)) для объекта Memory Manager (Менеджер памяти) соответствующего экземпляра SQL Server определяет, сколько именно виртуальной памяти (включая страницы в файле подкачки) используют подсистемы SQL Server. Это значение должно быть существенно ниже, чем объем физической оперативной памяти на сервере.

Если вы определили, что на сервере не хватает оперативной памяти, то естественно для решения проблемы ее нужно добавить. Однако отметим некоторые моменты, которые связаны с оперативной памятью для SQL Server 2005.

В 32-разрядных системах существуют ограничения на объем адресуемой оперативной памяти — 4 Гбайт. Если на сервере оперативной памяти больше (а такие системы все чаще встречаются на предприятиях), то для того, чтобы SQL Server мог использовать всю память, нужно предпринять необходимые действия и в операционной системе, и на самом SQL Server. В операционной системе нужно прописать для ее строки загрузки (пути ARC) в файл boot.ini дополнительный параметр /PAE (Physical Address Extension — расширение физических адресов), например:

multi(0)disk(0)risk(0)partition(2)\WINDOWS="Windows Server 2003, Enterprise RU" /no execute=opt out /fast detect /PAE

На SQL Server нужно включить параметр AWE enabled (Address Windowing Extensions). Включение его может выглядеть так:

sp_configure 'show advanced options', 1;

RECONFIGURE;

GO

sp_configure 'awe enabled', 1;

RECONFIGURE;

GO

После этого нужно перезапустить сервер.

Работа SQL Server в режиме AWE сопряжена с определенными проблемами. В частности, SQL Server никогда не отдает выделенную ему память AWE обратно, эта память никогда не выгружается в файл подкачки, могут возникнуть проблемы с распределением памяти AWE между экземплярами SQL Server, работающими на одном компьютере. Поэтому настоятельно рекомендуется при использовании режима AWE всегда устанавливать для SQL Server параметры min server memory (минимальное количество памяти, используемой SQL Server) и max server memory (максимальное количество памяти), например, так:

sp_configure 'min server memory', 1024;

RECONFIGURE;

GO

sp_configure 'max server memory', 6144;

RECONFIGURE;

GO

Вообще, если ваша задача "доросла" то таких требований к ресурсам, имеет смысл подумать о приобретении 64-разрядного сервера. Конечно, работать с 64-разрядной версией SQL Server 2005 не очень удобно (например, из-за необходимости запускать некоторые средства администрирования только на 32-разрядной системе, т. е. удаленно), но 64-разрядная система действительно может обеспечить большой выигрыш в производительности. Кроме того, 64-разрядные системы могут работать с памятью практически неограниченного объема.

Отметим еще один момент, который связан с увеличением физического количества оперативной памяти. При принятии решения о добавлении на сервер физической оперативной памяти всегда нужно помнить еще про один параметр — кэш второго уровня (L2 cache), который уже многие годы является компонентом процессора. Размер кэша второго уровня — это один из главных параметров, который отличает процессоры линейки Celeron от обычных Pentium и обычные Pentium — от серверных вариантов. Если кэша второго уровня недостаточно, то увеличение производительности при добавлении оперативной памяти будет происходить очень нелинейно, а в некоторых (совсем редких) случаях может и упасть. Оптимальный вариант — когда 2 Кбайт кэша второго уровня приходятся на каждый мегабайт физической оперативной памяти, хотя могут быть и другие варианты. В этом случае лучше посмотреть техническую документацию по серверной платформе — какой объем оперативной памяти для нее является рекомендуемым.

Получить учебные материалы по этому курсу