page life expectancy что означает
Анализируем использование памяти
Группа Microsoft Server Customer Advisory делится секретами повышения производительности
Влияние памяти
Иногда проблемы с производительностью прикладных задач проявляются следующим образом: пользователи могут сталкиваться с большим временем отклика приложений или медленной работой приложений. Тогда администраторы баз данных и разработчики начинают исследовать проблему, пытаясь найти причину этого явления. В остальных случаях внимательный администратор начинает искать причину, когда заметит необычное поведение системной характеристики, которую пользователи не могут видеть, вроде высокого процента использования центрального процессора или большого времени отклика от дисковой системы. Независимо от того, когда начинается исследование, в первую очередь необходимо выяснить, находится ли система под влиянием причин, связанных с памятью. Поскольку SQL Server разработан так, чтобы динамически управлять памятью, поиск решения может быть не таким простым, как может показаться. Например, в системе, в которой запущен SQL Server, процесс SQL Server (sqlservr.exe) обычно забирает большую часть памяти системы. Этот режим работы нормален, поскольку SQL Server спроектирован так, чтобы использовать как можно большее количество системной памяти до тех пор, пока никакие другие приложения не конкурируют за нее. Рост занятой SQL Server памяти не может быть ограничен параметром max server memory. Таким образом, объем памяти, который был распределен для процесса SQL Server, не поможет администратору понять, связана ли ошибка с памятью. О различиях использования памяти в 64-разрядных и 32-разрядных SQL Server рассказано во врезке «Управление памятью 64-разрядных и 32-разрядных систем». И хотя можно попробовать определить, связана ли проблема с памятью, посмотрев, не отведена ли память под процесс SQL Server на страницы, это не сработает, потому что SQL Server разработан так, чтобы избежать разбиения памяти на страницы.
Тогда как же обнаружить проблемы с памятью? Можно начать с просмотра счетчиков Performance Monitor (PerfMon): SQL Server:Memory Manager:Target Server Memory и SQL Server:Memory Manager:Total Server Memory. Счетчик Total Server Memory покажет, сколько памяти использует SQL Server. Если в течение некоторого времени Total Server Memory однозначно ниже, чем значение Target Server Memory, значит, в системе нет проблем с памятью. SQL Server не занимает больше памяти, чем он использует. Тем не менее, если величина Total Server Memory равна или превышает Target Server Memory, недостаток памяти может вызвать проблемы. Чтобы определить, где появляется недостаток памяти, нужно понять, каким способом SQL Server использует память. Соответствующие способы описаны в статье «Как работает память». Давайте посмотрим, чему можно научиться, если знать, как используется память в страничном кэше базы данных, кэше плана, рабочем пространстве запроса и блокировках.
Если значения счетчиков Buffer Cache Hit Ratio и Page life expectancy малы, то можно для стимуляции производительности приложений добавить дополнительное количество памяти. Однако перед тем как проверять оперативную память, надо произвести небольшое исследование скрытых причин. Возможно, ваш буферный кэш перегружен, потому что SQL Server работает со слишком большим количеством таблиц одновременно, или использует сканирование индексов вместо поиска по индексу, чтобы ограничить обращение к определенным строкам. Сканирование, особенно больших таблиц или индексов, скорее всего, приведет к падению значения Buffer Cache Hit Ratio, потому что маловероятно, чтобы все страницы большого объекта оставались в кэше памяти. Сканирование может также вызвать понижение в значении Page life expectancy за счет выдавливания других страниц, постоянно находящихся в буферном кэше. Поиск по индексу уменьшает обращение к специфическому диапазону строк и таким образом вызывает меньшее количество просмотров страницы. Счетчик SQL Server:Access Methods:Full Scans/sec в PerfMon позволяет контролировать число полных сканирований за секунду, выполняемых SQL Server. Если пользователь решит, что для него слишком частое применение полного сканирования нежелательно, можно использовать SQL Server Profiler и, просматривая события в Showplan Statistics в категории Performance, найти то из предложений SQL Server, которое приводит к полному сканированию. Анализируя данные в Profiler, можно определить, требуется ли добавлять индекс к таблице и возможно ли переупорядочить столбцы существующего индекса, чтобы использовать поиск по индексу вместо сканирования индекса. О том, как использовать информацию SHOWPLAN, рассказано в статье Microsoft «HOW TO: Troubleshoot Slow-Running Queries on SQL Server 7.0 or Later». (http://support.microsoft.com/default.aspx?scid=kb;en-us;243589).
Кэш плана
Иногда повторное использование плана неуместно. Например, если размер набора результатов запроса (или промежуточных результатов) сильно зависит от параметров, описанных в предикате WHERE. В таких случаях стратегии обращений для различных операторов должны быть различными. Более подробную информацию о случаях, когда повторное использование плана неуместно, можно найти в «Query Recompilation in SQL Server 2000», http://msdn.microsoft.com/library/default.aspx?url=/library/en-usdnsql2k/html/sql_queryrecompilation.asp. Однако в целом повторное использование плана уменьшает нагрузку на процессор и может заметно улучшить производительность OLTP-систем.
Память рабочего пространства
Сложная система поддержки принятия решений или приложения для хранилища данных обычно требует памяти для рабочего пространства, результатом чего является высокое значение счетчика SQL Server:Memory Manager:Granted Workspace Memory (KB). В таких случаях важно контролировать длину очереди на предоставление памяти (как было описано в статье «Как работает память»), проверяя счетчик SQL Server:Memory Manager:Memory Grants Pending. Длинная очередь, особенно по сравнению со счетчиком SQL Server:Memory Manager:Memory Grants Outstanding, означает, что система перегружена слишком большим количеством запросов, интенсивно потребляющих память. Можно использовать Profiler, чтобы понять, какие запросы используют выделение памяти и почему. Поле Integer Data из трассировщика события 28 в Profiler показывает размер предоставленной памяти под оператор в килобайтах. Анализ событий в Showplan для оператора может подсказать, как обнаружить отсутствующий индекс для операций JOIN или SORT. Или анализ может показать, что запрос слишком общий и нуждается в указании имени пользователя или приложения, тогда требуется уточнить запрос для обработки меньшего количества строк.
SQL Server в значительной степени полагается на статистику при оценке количества рабочей памяти, которое потребуется для обработки запроса. Например, для объединения хешированием приблизительное число строк и размер строки первой таблицы для построения объединения (формирующей объединение) определяет, сколько памяти потребуется для присоединения. Проблемы возникают, если оценка неверна. Если оценка занижена, хэш-таблица не будет соответствовать размеру выделенной памяти, и строки будут скидываться на диск, замедляя выполнение запроса. События Hash Warning и Sort Warning из категории Errors and Warnings в Profiler укажут на такое переполнение. Если оценка слишком высока, SQL Server решит, что нужно выполнить запрос с большими допущениями, чем это требуется фактически, и запрос может находиться в очереди для предоставления памяти сверх необходимого. Пользователь может задействовать событие Show Plan Statistics, чтобы точно определить, насколько оцененное оптимизатором запросов количество строк начинает отличаться от фактического количества обработанных строк. В целом, статистика дает оптимизатору запросов больше шансов точно оценить размер. Иногда характер распределения данных или сложность запроса не позволяет точно предсказать результат. Пользователь в таких ситуациях должен использовать хинты объединения (типа HASH JOIN или LOOP JOIN) или хинты порядка объединения (типа FORCE ORDER).
Блокировка памяти
Создание пользовательской рабочей области памяти
Использование памяти SQL Server заметно влияет на производительность системы. Понимание того, как SQL Server использует память и как управлять этим процессом, поможет пользователю понять, сталкивается ли его система с нехваткой памяти и решить связанные с этим проблемы. Общаясь с клиентами, которые столкнулись со снижением производительности, связанным с памятью в SQL Server, специалисты группы SQL Server Customer Advisory Team всегда рекомендуют стараться устранять основные причины нехватки памяти, прежде чем пользователь примет решение увеличить память. Здесь уместно вспомнить аналогию с прохудившимся бензобаком в автомобиле. Несомненно, наличие большого бака поможет отсрочить остановку системы, но в конечном счете, пока хозяин не найдет и не устранит утечку, топливо из бака будет вытекать.
Управление памятью 64-разрядных и 32-разрядных систем
Важно обратить внимание на то, что SQL Server использует память AWE только в страничном кэше базы данных (то есть для данных и индексных страниц) и при этом может использовать физическую память вне виртуальной памяти процесса. Все другие способы использования памяти, включая кэш плана, память рабочего пространства запроса, блокировки и другие структуры типа пользовательских подключений, курсоров и пространств, используемых утилитами для резервирования и восстановления, ограничены виртуальным адресным пространством. Тем не менее, если пользовательское приложение для SQL Server сталкивается с нехваткой памяти в этих частях системы, добавление дополнительной память свыше 3 Гбайт на 32-разрядных системах может принести лишь небольшую выгоду. В таких случаях пользователь может подумать о миграции на 64-разрядную систему. Системы на 64-разрядах особенно хорошо показали себя в работе информационных хранилищ и в больших ERP-системах. Дополнительную информацию о потенциальных преимуществах SQL Server (64 разряда) можно найти в статье по адресу http://www.microsoft.com/sql/64bit/productinfo/SQL64bitAdvantages.asp. О том, как настроить память AWE с SQL Server, рассказано в статье, опубликованной по адресу http://support.microsoft.com/default.aspx?scid=kb;en-us;274750.
Оптимизация через настройки параметров запросов в планах повторного использования
Несколько методов позволяют создавать приложения таким образом, чтобы разрешить оптимизатору запросов повторное использование одного и того же плана. По определению, хранимые процедуры и их планы запросов используются многократно. Тогда если пользователь создает хранимую процедуру, которая задействует параметры вместо ввода переменных, SQL Server может повторно использовать план при работе той же хранимой процедуры. Для пиковой производительности пользовательское приложение должно вызвать хранимые процедуры, через применение запроса Remote Procedure Call (RPC). Запросы RPC пропускают большую часть разбора предложения и обработки параметров в SQL Server и работают быстрее, чем оператор T-SQL EXECUTE. Синтаксис RPC можно найти в SQL Server 2000 Books Online (BOL). Или, как показано в Листинге А, можно использовать процедуру sp_executesql, которая позволит SQL Server повторно применить тот же план двум операторам выполнением отделения констант от кода предложения. В качестве альтернативы можно улучшить повторное использование плана, применяя модель готовности/выполнения, обеспеченную обращением к данным через API типа ODBC или OLE DB. Описание соответствующих API для ODBC можно найти в статье «How to Prepare and Execute a Statement (ODBC)» по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht_6_odbcht_66 0k.asp)и для OLE DB в MSDN OLE DB Programmers Reference по адресу http://msdn.microsoft.com/library/default.asp?url=/library/enus/oledb/htm/oledbicommandprepare__prepare.asp.
Листинг А. Код, использующий хранимую процедуру sp_executeSQL, что помогает повторно задействовать план запроса.
Поделитесь материалом с коллегами и друзьями
Показатель Page Life Expectancy (PLE)
Часть первая ( Paul Randal )
Что означает PLE?
В Интернете есть всевозможные неверные утверждения об ожидаемой продолжительности жизни страниц, и наиболее вопиющими являются те, в которых указывается, что значение 300 является порогом того, о чем вам следует беспокоиться.
Чтобы понять, почему это утверждение настолько вводит в заблуждение, вам нужно понять, что такое PLE на самом деле.
Определение PLE-это ожидаемое время в секундах, в течение которого страница файла данных, считанная в пул буферов (кэш в памяти страниц файлов данных), останется в памяти, прежде чем будет вытеснена из памяти, чтобы освободить место для другой страницы файла данных. Другой способ думать о PLE-это мгновенное измерение давления на пул буферов, чтобы освободить место для страниц, считываемых с диска. Для обоих этих определений лучше использовать большее число.
Что такое хороший порог PLE?
Число 300 означает, что весь ваш буферный пул эффективно очищается и перечитывается каждые пять минут. Когда Microsoft впервые указала пороговое значение для PLE 300 примерно в 2005/2006 году, это число, возможно, имело больше смысла, поскольку средний объем памяти на сервере был намного ниже.
В настоящее время, когда серверы обычно имеют 64 ГБ, 128 ГБ и более объем памяти, примерно такое количество данных, считываемых с диска каждые пять минут, скорее всего, станет причиной проблемы с производительностью
На самом деле, к тому времени, когда PLE находится на отметке 300 или ниже, ваш сервер уже находится в тяжелом положении. Вы бы начали беспокоиться задолго до того, как уровень PLE станет настолько низким.
Итак, какой порог следует использовать, когда вам следует беспокоиться?
Ну, в том-то и дело. Я не могу назвать вам порог, так как это число будет варьироваться для всех. Если вы действительно, действительно хотите использовать число, мой коллега Джонатан Кехайяс придумал формулу:
( Память буферного пула в ГБ / 4 ) x 300 (Но это очень приблизительно)
Я не люблю рекомендовать какие-либо цифры. Я советую вам измерять свой PLE, когда производительность находится на желаемом уровне – это пороговое значение, которое вы используете.
Итак, вы начинаете беспокоиться, как только PLE опускается ниже этого порога? Нет. Вы начинаете беспокоиться, когда PLE опускается ниже этого порога и остается ниже этого порога, или если он резко падает, и вы не знаете почему.
Это связано с тем, что существуют некоторые операции, которые могут привести к падению PLE (например, иногда это может сделать запуск DBCC CHECKDB или перестроение индекса), и они не вызывают беспокойства. Но если вы видите большое падение PLE и не знаете, что его вызывает, именно тогда вам следует беспокоиться.
Вам может быть интересно, как DBCC CHECKDB может вызвать падение PLE. Это связано с тем, что предоставление памяти для выполнения запроса для DBCC CHECKDB неправильно рассчитано оптимизатором запросов и может привести к значительному уменьшению размера буферного пула (память выделяется из буферного пула) и последующему снижению PLE.
Как Вы Контролируете PLE?
Это самая сложная часть. Большинство людей сразу перейдут к объекту производительности диспетчера буферов в PerfMon и будут отслеживать счетчик ожидаемой продолжительности жизни страницы. Является ли это правильным подходом? Скорее всего, нет.
Я бы сказал, что сегодня подавляющее большинство серверов используют архитектуру NUMA, и это оказывает глубокое влияние на то, как вы отслеживаете PLE.
Когда задействован NUMA, пул буферов разделяется на буферные узлы, с одним буферным узлом на узел NUMA, который может «видеть» SQL Server. Каждый узел буфера отслеживает PLE отдельно, а счетчик ожидаемой продолжительности жизни страницы-это среднее значение PLE узла буфера. Если вы просто отслеживаете общий объем буферного пула, то давление на один из буферных узлов может быть замаскировано усреднением (смотрите часть вторая).
Поэтому, если ваш сервер использует NUMA, вам необходимо отслеживать отдельные счетчики Buffer Node:Page life expectancy (для каждого узла NUMA будет один объект производительности буферного узла), в противном случае достаточно контролировать счетчик Buffer Manager:Page life expectancy.
Еще лучше использовать инструмент мониторинга, такой как SQL Sentry Performance Advisor, который покажет этот счетчик как часть панели мониторинга с учетом узлов NUMA на сервере и позволит вам легко настраивать оповещения.
Примеры использования Советника по производительности
Ниже приведен пример части снимка экрана из Performance Advisor для системы с одним узлом NUMA:
На правой стороне захвата розовая пунктирная линия-это число между 10.30 утра и примерно 11.20 утра-оно неуклонно растет до 5000 или около того, действительно здоровое число. Незадолго до 11.20 утра происходит огромное падение, а затем он снова начинает подниматься до 11.45 утра, где снова падает.
Обычно это то, что вы увидите, если пул буферов заполнен, все страницы используются, а затем выполняется запрос, который приводит к считыванию огромного количества различных данных с диска, вытесняя большую часть того, что уже находится в памяти, и вызывая резкое падение PLE. Если бы вы не знали, что вызвало нечто подобное, вы бы хотели провести расследование, как я опишу ниже.
В качестве второго примера, снимок экрана ниже сделан с одного из наших удаленных клиентов DBA, где на сервере есть два узла NUMA (вы можете видеть, что есть две фиолетовые строки PLE), и где мы широко используем Performance Advisor:
На сервере этого клиента каждое утро около 5 утра запускается задание по обслуживанию индекса и проверке согласованности, в результате чего PLE падает в обоих буферных узлах. Это ожидаемое поведение, поэтому нет необходимости расследовать, пока PLE снова поднимается в течение дня.
Что Вы можете сделать с падением PLE?
Если причина падения PLE неизвестна, вы можете сделать несколько вещей:
Если проблема возникает сейчас, выясните, какие запросы вызывают чтение, используя DMV sys.dm_os_waiting_tasks, чтобы узнать, какие потоки ожидают чтения страниц с диска (т. Е. Те, которые ожидают PAGEIOLATCH_SH), а затем исправьте эти запросы.
Если проблема возникла в прошлом, найдите в DMV sys.dm_exec_query_stats запросы с большим количеством физических считываний или используйте средство мониторинга, которое может предоставить вам эту информацию (например, представление верхнего SQL в Performance Advisor), а затем исправьте эти запросы.
Сопоставьте падение PLE с запланированными заданиями агента, которые выполняют обслуживание базы данных.
Найдите запросы с очень большой памятью для выполнения запросов, предоставляющей память, с помощью DMV sys.dm_exec_query_memory_grants, а затем исправьте эти запросы.
Резюме
Не попадайтесь в ловушку веры в какой-либо рекомендуемый порог, который вы можете прочитать в Интернете. Лучший способ реагировать на изменения PLE – это когда PLE опускается ниже вашего уровня комфорта и остается там-это признак проблемы с производительностью, которую вам следует изучить.
Часть вторая ( Paul Randal )
Существует много споров по поводу ожидаемой продолжительности жизни страницы счетчика объектов производительности диспетчера буферов – в основном из-за того, что люди продолжают указывать 300 в качестве порога для того, чтобы начать беспокоиться о наличии проблемы (что в наши дни просто полная чушь). Это слишком *низко*, чтобы быть точкой, в которой можно начать беспокоиться, если ваш PLE упадет и останется там. Джонатан придумал лучший номер для использования – в зависимости от размера вашего буферного пула – см. Нижнюю часть его поста здесь.
Но я пишу сегодня не поэтому: я хочу объяснить, почему в большинстве случаев Ожидаемая продолжительность жизни страницы на самом деле не дает вам полезной информации.
Большинство новых систем сегодня используют NUMA, и поэтому пул буферов разделен и управляется для каждого узла NUMA, при этом каждый узел NUMA получает свой собственный поток lazy writer, управляет своим собственным списком свободных буферов и занимается распределением локальной памяти узла. Думайте о каждом из них как о мини-буферном пуле.
Счетчик Buffer Manager:Page Life Expectancy рассчитывается путем добавления PLE каждого мини-буферного пула, а затем вычисления среднего значения. Но это не среднее арифметическое, как мы все думали всегда, это среднее гармоническое (см. Википедию здесь), поэтому значение ниже среднего арифметического. (5/11/2015: Спасибо Мэтту Слокуму (b | t) за указание на расхождение со средним арифметическим в большой системе NUMA и за то, что заставил меня углубиться в это подробнее, и моему другу Бобу Дорру из CSS за то, что он углубился в код.)
Что это значит? Это означает, что общий PLE не дает вам истинного представления о том, что происходит на вашей машине, так как один узел NUMA может испытывать нехватку памяти, но *общий* PLE будет лишь незначительно снижаться. У одного из моих друзей, который является ведущим полевым инженером и MCM, только что была такая ситуация сегодня, что побудило к этому сообщению в блоге. Загадка заключалась в том, как может происходить более 100 ленивых записей в секунду, когда общий PLE относительно статичен – и в этом была проблема.
Например, для машины с 4 узлами NUMA, где PLE каждого составляет 4000, общий PLE составляет 4000.
Расчет таков: добавьте обратные числа (1000 x PLE) для каждого узла, разделите их на количество узлов, а затем разделите на 1000.
В моем примере это 4 / (1/(1000 x 4000) + 1/(1000 x 4000) + 1/(1000 x 4000) + 1/(1000 x 4000)) / 1000 = 4000.
Теперь, если один из них упадет до 2200, общий PLE снизится только до: 4 / (1/(1000 x 2200) + 1/(1000 x 4000) + 1/(1000 x 4000) + 1/(1000 x 4000)) / 1000 = 3321.
Если бы у вас было установлено оповещение о снижении PLE на 20%, оно бы не сработало, даже если бы один из буферных узлов находился под высоким давлением.
И вы тоже должны быть осторожны, чтобы не слишком остро реагировать. Если один из них снизится до 200, общий PLE снизится только до: 4 / (1/(1000 x 200) + 1/(1000 x 4000) + 1/(1000 x 4000) + 1/(1000 x 4000)) / 1000 = 695, что может заставить вас подумать, что сервер сильно страдает по всем направлениям.
На компьютерах NUMA вам необходимо просматривать счетчики Buffer Node:Page Life Expectancy для всех узлов NUMA, иначе вы не получите точного представления о нехватке памяти в буферном пуле и поэтому можете пропустить или чрезмерно реагировать на проблемы с производительностью. И отрегулируйте пороговое значение Джонатана в соответствии с количеством имеющихся у вас узлов NUMA.
Вы можете просмотреть активность lazywriter для каждого узла NUMA, выполнив поиск потоков lazywriter в файле sys.dm_exec_requests.
Надеюсь, это поможет!
Дополнение ( Brent Ozar )
PLE увеличивается на 1 секунду за каждую секунду, когда у вас нет недостатка в памяти. Перезапустите экземпляр SQL Server и посмотрите PLE: он начинается с 1 и увеличивается на 1 за каждую секунду времени безотказной работы. 5 минут безотказной работы = 300 пл. В течение первых 5 минут не похоже, что ваш сервер испытывает нехватку памяти – он просто проснулся, черт возьми. Дайте ему 15-20 минут. Думаю, PLE почти бесполезен в течение этого промежутка времени.
Снижение PLE может быть вызвано некоторыми операциями. По умолчанию любой выполняемый запрос может получить доступ к памяти размером 25% от вашего буферного пула. Выполните несколько таких запросов одновременно, и ваш пул буферов истощится, но PLE не обязательно упадет. Однако в тот момент, когда выполняется несвязанный запрос и требуется получить данные, которые не кэшируются в оперативной памяти, ваш PLE катастрофически упадет. Какие запросы являются причиной? Запросы, получающие большие гранты, или запросы, выполняющие чтение?
Имея это в виду, я полностью удалил предупреждения о PLE из sp_BlitzFirst.
Переводчик выражает благодарность Виктору Богачеву – автору и ведущему «Подготовка к 1С:Эксперту по технологическим вопросам. Основной курс» за спонсорскую помощь.
SQLShack
Page Life Expectancy (PLE) in SQL Server
Page Life Expectancy (PLE) is an age of a data page in seconds in the buffer cache or buffer memory after querying the tables with the loading data page into the buffer memory. Page Life Expectancy value indicates the memory pressure in allocated memory to the SQL Server instance. In most of the cases, a page will be dropped from buffer periodically.
The basic fundamental of Microsoft SQL Server for querying data is to load the necessary data pages into the buffer pool from the disk and return it to the client. If the buffer does not have enough space to process it, then the oldest data pages will be eradicated to make some room as required for new pages.
As a traditional standard, PLE (Page Life Expectancy) should not be less than 300 seconds (5 Minutes), but actually, that value can fluctuate based on the SQL Server load. Anyway, a buffer is managed by the numa node, and that can be divided into the multiple numa nodes. Even, it can be more challenging to manage load distribution for the various numas when heavy workload occurs. PLE can raise performance issues by building pressure on buffer when your PLE goes down and not coming up for a while. There can be many more activities which can cause this issue.
Get PLE for your SQL Server instance with the help of T-SQL statement
Here, cntr_value represents the PLE which is 29570 in the above query result set.
We always assume that the query performance is degrading by the lake of buffer memory, and SQL Server does not have enough buffer pool to cache the information. It is not blaming the side for the worst query performance because a query execution plan is everything. If your query plan is improper, then the table will be scanned with unnecessary loading data to the buffer memory.
The above situations discuss the factors on what PLE can get down. But what about PLE getting down at a specific time? Hopefully, each production SQL Server will have the internal data maintenance task and standard maintenance, which is running by the SQL Server job and executing on the off-peak hours. Even, you can observe fluctuation in PLE (Page Life Expectancy) when any heavy I/O performs by the SQL Server with the big CRUD operation.
Monitoring Page Life Expectancy
PLE counter value is an essential measurement of pressure on the buffer memory in units of seconds. Users can capture it with the help of SSMS, any other third-party tools, or Microsoft performance monitor; It returns average value always. Users can find the current value by the above T-SQL statement. Still, analysis is required in a particular period to see if fluctuation happens in point of time. Users can use the Windows Performance Monitor by adding the PLE counter to track the same.
Multiple SQL Server instances can be configured in single SQL Server. For monitoring a particular SQL Server instance, the user can select in the counter drop-down list of the performance monitor screen. In the below image, you can see that the PLE counter exists in MSSQL$JERRY: Buffer Manager.
Here, MSSQL$JERRY is SQL Server instance service details, and Buffer Manager is the object name.
For example, the above SQL Server instance service is restarted to get some fluctuation in Page Life Expectancy. After restarting it, the PLE count starts from 0 and increases with the querying data in the background. Again count is decreased when memory allocation is reduced and data is fetched from the tables in the background.
Here, we can conclude that the PLE count will be decreased when buffer memory does not have enough space to store new data pages when any READ/WRITE operation is performed.
How to Calculate Page Life Expectancy
As per Microsoft standard, we follow a rule of 300 seconds. If PLE goes less than 300 seconds (5 Minutes), then memory pressure is very high, and we have to take care of the performance side. Still, that calculation was for just 4GB memory allocation to the SQL Server. For your server, it should be different as per the formula. You should worry about the SQL Server instance when PLE goes down than the below calculation:
PLE (Page Life Expectancy) threshold = ((Buffer Memory Allocation (GB)) / 4 ) * 300
For example, the machine is configured with 128GB, and 110GB is allocated to the SQL Server instance, then the PLE threshold will be as below:
PLE (Page Life Expectancy) threshold = (110 / 4) * 300
PLE (Page Life Expectancy) threshold = 8250 Seconds
No one can say that what number will be recommended for the standard threshold because each SQL Server has different configurations according to the use case and requirement. If your PLE goes down suddenly, then the first thing should be to check memory allocation. Is it enough amount of size for the SQL Server? If yes, then check the currently executing request, is there any long-running thread that consumes more memory? If yes, then review the currently executing query statement.
The performance will be based on the disk, which is a bit slower than the primary memory. Eventually, it produces a lot of disk IO and stresses on the storage because the memory is not getting processed efficiently by the server. Unnecessary memory usage issue should be observed and take a chance to get it optimized with a proper investigation.
Users can monitor it with querying on sys.dm_os_performance_counters DMV to find that PLE threshold is crossing the underline or not. If the counter value found is less than your calculation, then it should trigger a mail to the responsible team to observe and monitor the memory pressure-related parameters. We get the indication regarding the increased pressure on the buffer pool when page life expectancy drops down to a typical value and stays there for a more extended period. Possibly this is the sign that we might need more memory. It is advisable to add more memory when the workload is hiking gradually, and PLE is moving downward sluggishly. However, when something else is using more memory (e.g., plan cache). In this scenario, buffer pool pressure is increased, but there is no change in workload. A consecutive monitor enables the ability to measure stuff and evaluate it over more issues. After doing this, it is possible to let OpsMgr check the value and generate an alert when the value meets a specific threshold for X values.
Conclusion
PLE (Page Life Expectancy) is not a single buffer manager parameter which can affect the SQL Server performance; there are many more in the list of buffer manager. We can consider that the buffer memory pressure can be the primary issue if found. Nowadays, we see bigger memory boxes and quite common to have PLE in the thousands range.
There are a lot of things to monitor for DBAs in the production environment. If you encounter any buffer memory side issue, Windows Performance Monitor helps a lot to observe real-time statistics.