環境内のいくつかの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操作を実行する)。 lowは、メモリのデータページが物理的な新しいページで定期的に上書きされることを示します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にキャッシュしておく)。
一般的には、メモリに保持されているため、負荷パターンが高いほど、負荷パターンの処理が速くなります。非常に低い場合は、メモリ不足が原因のパフォーマンスの問題を示している可能性があります。
ただし、読み取り値が低いということは、必ずしも問題があることを意味するわけではありません。たとえば、多くのページを使用する大量のプロセスが大量に発生し、それらを取り込み、さらにスペースを空けるためにドロップした後、低い可能性があります。たとえば、毎日の終わりに下がると思われるグラフは、夜間の管理ジョブ(バックアップ、データのアーカイブ、その他の夜間の処理)が原因である可能性があります。