Что Page Life Expectancy говорит об этом случае?

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

Меня интересует один счетчик: продолжительность жизни страницы. Это выглядит по-разному на каждой машине. Почему это часто меняется в некоторых случаях и что это значит?

Пожалуйста, посмотрите на данные за последнюю неделю, собранные на нескольких разных машинах. Что вы можете сказать о каждом случае?

Сильно используемый производственный экземпляр (1):

Умеренно используемый выпуск продукции (2)

Редко используемый тестовый экземпляр (3)

Сильно используемый производственный экземпляр (4)

Умеренно используемый тестовый экземпляр (5)

Сильно используемое хранилище данных (6)

РЕДАКТИРОВАТЬ: я добавляю вывод SELECT @@ VERSION для всех этих серверов:

Instance 1: Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 
Jun 17 2011 00:54:03 Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 2: Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 
Oct 19 2012 13:38:57 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 3: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
    Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 4: Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 5: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 6: Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr 2 2010 15:48:46 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Я также выполнил следующий запрос на машинах:

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

и он возвратил 2 или 3 строки для каждого сервера:

Instance 1: 0; 64; 1
Instance 2: 0; 64
Instance 3: 0; 64
Instance 4: 0; 64
Instance 5: 0; 64
Instance 6: 0; 64; 1

Что это значит? На этих серверах работает NUMA?

Взято из MSDN: - https://msdn.microsoft.com/en-us/library/ms189628.aspx

Ожидаемая продолжительность жизни страницы - указывает количество секунд, в течение которых страница будет оставаться в пуле буферов без ссылок.

SQL всегда ищет страницы данных в памяти. Если страница данных отсутствует в памяти, SQL придется перейти на диск (выполнить физическую операцию ввода-вывода), чтобы получить данные, необходимые для выполнения запроса. Если у вас низкий счетчик PLE, это означает, что страницы данных в памяти регулярно перезаписываются новыми страницами, поступающими от физических операций ввода-вывода. Физические операции ввода-вывода являются дорогостоящими, а это означает, что производительность вашего экземпляра SQL будет ухудшена. Таким образом, вы хотите, чтобы ваш счетчик PLE был как можно выше.

Игнорируйте любой совет, который вы видите в Интернете, который упоминает 300 как хороший порог для этого счетчика

Этот порог исходит из тех дней, когда память была ограничена (вспомним 32-битные системы). Теперь у нас есть 64-битные системы, которые могут иметь ТБ ОЗУ, поэтому этот совет очень устарел.

Во-первых, вы ограничили память SQL? Если да, сколько свободной памяти осталось? Можно ли увеличить лимит?

Второе, что я хотел бы найти на ваших серверах, выполняются ли какие-либо работы по обслуживанию? Проверьте задания, выполняющие перестроения индекса, обновите статистику или операции DBCC CHECKDB. Они выполняют большое количество операций чтения и могут быть причиной вашей плоской подкладки PLE,

Затем, так как вы используете SQL Server 2008 +, вы можете настроить сеанс расширенного события для захвата входящих запросов, которые выполняют большое количество операций чтения. Вот код для этого:

CREATE EVENT SESSION [QueriesWithHighLogicalReads] ON SERVER 
ADD EVENT sqlserver.sql_batch_completed(
   ACTION(sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_stack,sqlserver.username)
     WHERE ([logical_reads]>200000))
ADD TARGET package0.event_file(SET filename=N'C:\SQLServer\XEvents\QueriesWithHighLogicalReads.xel')
GO

Это будет захватывать все запросы на вашем сервере, которые выполняют более 200000 логических чтений. Я не знаю, сколько у вас памяти на каждом сервере, так что вы можете настроить эту цифру. Как только это будет создано, вы можете начать сеанс, выполнив: -

ALTER EVENT SESSION [QueriesWithHighLogicalReads]
ON SERVER
STATE = START;
GO

А затем запросите сеанс, выполнив: -

WITH CTE_ExecutedSQLStatements AS
(SELECT
[XML Data],
[XML Data].value('(/event[@name=''sql_statement_completed'']/@timestamp)[1]','DATETIME')    AS [Time],
[XML Data].value('(/event/data[@name=''duration'']/value)[1]','int')                        AS [Duration],
[XML Data].value('(/event/data[@name=''cpu_time'']/value)[1]','int')                        AS [CPU],
[XML Data].value('(/event/data[@name=''logical_reads'']/value)[1]','int')                   AS [logical_reads],
[XML Data].value('(/event/data[@name=''physical_reads'']/value)[1]','int')                  AS [physical_reads],
[XML Data].value('(/event/action[@name=''sql_text'']/value)[1]','varchar(max)')             AS [SQL Statement]
FROM
    (SELECT 
    OBJECT_NAME              AS [Event], 
    CONVERT(XML, event_data) AS [XML Data]
FROM 
    sys.fn_xe_file_target_read_file
('C:\SQLServer\XEvents\QueriesWithHighLogicalReads*.xel',NULL,NULL,NULL)) as v)

SELECT
[SQL Statement]     AS [SQL Statement],
SUM(Duration)       AS [Total Duration],
SUM(CPU)            AS [Total CPU],
SUM(Logical_Reads)  AS [Total Logical Reads],
SUM(Physical_Reads) AS [Total Physical Reads]
FROM
CTE_ExecutedSQLStatements
GROUP BY
[SQL Statement]
ORDER BY
[Total Logical Reads] DESC
GO

Будьте осторожны при запуске этого! Размер файла может увеличиться, поэтому сначала проверьте его на экземпляре разработки. Вы можете установить макс. размер файла, но я не включил это здесь. Вот ссылка MSDN для расширенных событий: - https://msdn.microsoft.com/en-us/library/hh213147.aspx

Регулярно следите за этим сеансом, и, надеюсь, он должен принимать любые поступающие запросы, которые выровняли бы вашу PLE.

Дальнейшее чтение -

Блог MSDN на PLE - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectancy.aspx

Видео о настройке расширенных событий - https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-using-extended-events/ (Это из моего собственного блога, поэтому я сожалею о бесстыдной саморекламе )

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

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

Низкое чтение не всегда означает, что есть проблема: например, оно может быть низким после массивного одноразового перенасыщения процессов, которые использовали много страниц, поэтому их вводили и отбрасывали, чтобы освободить место для большего. Например, график, который, по-видимому, падает в конце каждого дня, может быть вызван ночными административными заданиями (резервное копирование, архивирование данных, другая ночная обработка).