Page Life Expectancyはインスタンスについて何と言っていますか？

環境内のいくつかのSQL Serverインスタンスに監視ソフトウェアをインストールしました。ボトルネックを見つけて、パフォーマンスの問題をいくつか修正しようとしています。一部のサーバーでより多くのメモリが必要かどうかを確認したい。

1つのカウンター、ページの平均余命に興味があります。それはすべてのマシンで異なって見えます。一部のインスタンスで頻繁に変更されるのはなぜですか？それはどういう意味ですか？

いくつかの異なるマシンで収集された先週のデータを見てください。各インスタンスについて何が言えますか？

頻繁に使用される本番インスタンス（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のメモリを制限しましたか？その場合、使用可能なメモリはどのくらい残っていますか？制限を引き上げることはできますか？

私があなたのサーバーで探している2番目のものは、実行中のメンテナンスジョブがありますか？インデックスの再構築、統計の更新、または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にキャッシュしておく）。

一般的な対策として、メモリに保持されているため、負荷パターンが高いほど、負荷パターンの処理が速くなります。非常に低い場合は、メモリ不足によりパフォーマンスに問題がある可能性があります。

ただし、読み取り値が低いということは、必ずしも問題があることを意味しているわけではありません。たとえば、多くのページを使用した大量のプロセスが大量に発生したために、ページを取り込み、スペースを空けるためにドロップした後、低い可能性があります。たとえば、毎日の終わりに下がると思われるグラフは、夜間の管理ジョブ（バックアップ、データのアーカイブ、その他の夜間の処理）が原因である可能性があります。