인스턴스에 대한 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이 디스크로 이동해야합니다 (물리적 IO 작업 수행). PLE 카운터가 낮 으면 메모리의 데이터 페이지가 물리적 IO 조작에서 오는 새 페이지로 정기적으로 겹쳐 쓰여짐을 나타냅니다. 물리적 IO 작업은 비용이 많이 들기 때문에 SQL 인스턴스의 성능이 저하 될 수 있습니다. 따라서 당신은 당신의 PLE 카운터가 가능한 한 높아지기를 원할 것입니다.

이 카운터에 대한 임계 값으로 300을 언급하는 온라인 조언을 무시하십시오.

이 임계 값은 메모리가 제한되었던 시절 (32 비트 시스템을 고려)에서 비롯됩니다. 이제 우리는 TB의 RAM을 가질 수있는 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을 평평하게하는 쿼리를 가져와야합니다.

추가 자료-

PLE의 MSDN 블로그-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/ (그것은 내 자신의 블로그에서 뻔뻔한 자체 승진에 대해 너무 미안 )

페이지 수명은 디스크에서 방금 읽은 페이지가 메모리에서 다른 페이지로 밀려나거나 파괴되기 전에 메모리에서 정지 될 때까지의 시간을 측정 한 것입니다 (예 : 해당 페이지가 디스크에서 할당 해제 될 필요가 없음) RAM에 사본을 캐시하려면).

일반적으로 메모리에 물건이 보관되어 있기 때문에로드 패턴이 더 빨리 처리 될수록 높아집니다. 매우 낮 으면 메모리 부족으로 인한 성능 문제를 나타낼 수 있습니다.

판독 값이 낮다고해서 항상 문제가있는 것은 아닙니다. 예를 들어, 많은 페이지를 사용하는 대량의 일회성 프로세스로 인해 낮아질 수 있으므로 더 많은 공간을 확보 할 수 있습니다. 예를 들어 매일 끝날에 떨어지는 것처럼 보이는 그래프는 야간 관리 작업 (백업, 데이터 보관, 기타 야간 처리)으로 인해 발생할 수 있습니다.