Що говорить Про тривалість життя сторінки про примірник?

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

Мене цікавить одна зустрічна: тривалість життя сторінки. Це виглядає по-різному на кожній машині. Чому вона часто змінюється в деяких випадках і що це означає?

Погляньте, будь ласка, на дані минулого тижня, зібрані на кількох різних машинах. Що ви можете сказати про кожен екземпляр?

Сильно використовуваний екземпляр виробництва (1):

Помірно використані виробничі коефіцієнти (2)

Рідко використовуваний тестовий примірник (3)

Сильно використовуваний виробничий екземпляр (4)

Помірно використаний тестовий примірник (5)

Сильно використаний склад даних (6)

EDIT: Я додаю вихід 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/ (Це з мого власного блогу, так шкода безсоромної самореклами )

Тривалість життя сторінки - це показник того, як довго ви можете очікувати, що сторінка, щойно прочитана з диска, зависає в пам'яті, перш ніж її виштовхне щось інше або знищить (тобто ця сторінка розміщена на диску, щоб не було потреби щоб зберегти копію, кешовану в ОЗП).

Як правило, чим вище, тим швидше буде оброблятися ваша схема завантаження, оскільки речі зберігаються в пам'яті. Якщо він дуже низький, це може вказувати на продуктивність, викликану голодною пам’яттю.

Хоча низьке читання не завжди означає, що існує проблема: наприклад, вона може бути низькою після масивної одноразової перенасиченості процесів, які використовували багато сторінок, тому вони заносили їх, і вони відпадали, щоб звільнити більше місця. Ваш графік, який, здається, падає наприкінці кожного дня, наприклад, може бути викликаний нічними адміністративними роботами (резервне копіювання, архівування даних та інша обробка за ніч).