web-dev-qa-db-ja.com

クエリでPLEを削除する

会社では、非常に大きなデータベースのプロジェクトに取り組んでいます。 100GBのRAMを使用します。最初にクエリを実行する前に奇妙なことは何ですかPLEは11k〜です。実行後、約70に下がります。いずれにしても、15分後にPLEを再度チェックすると、約1k〜になり、もう一度クエリを実行すると、60に下がります。なぜですか。クエリを実行する間に時間内にPLEが増加した場合、それはすべての必要なデータがキャッシュにあることを意味しませんか？もしそうなら、15分後に同じクエリを実行すると、PLEが再びドロップするのですか？

これがクエリです：

select
    ResultType = case r.TypeID
        when 'dlp' then 'DLP'
        when 'bill' then 'BILL'
        when 'evtlog' then 'EVTLOG'
    end,
    SerialNumber, 
    ESerialNumber, 
    ResultDateTime, 
    DateTimeStamp as SavedInSystem
from 
    Results r
where
    TypeID in ('typeid1','typeid2')
    and DateTimeStamp > '2016-05-19 23:00:00'
    and SerialNumber in ('serialnumber')

datetimestampにクラスター化インデックスがあり、typeid, datetimestampとresultdatetime, resultid, typeidにクラスター化されていないインデックスがいくつかあります... @update

    select
(physical_memory_in_use_kb/1024)Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB,
(total_virtual_address_space_kb/1024 )Total_VAS_in_MB,
process_physical_memory_low,
process_virtual_memory_low
from sys. dm_os_process_memory

戻り値

Memory_usedby_Sqlserver_MB  Locked_pages_used_Sqlserver_MB  Total_VAS_in_MB process_physical_memory_low process_virtual_memory_low
102569  0   134217727   0   0

ここにカウンターがあります。2012年のバージョンでfreepagesが削除されたため、他のカウンターをいくつか追加しました

object_name counter_name instance_name cntr_value cntr_type
MSSQL$ServerNameC3SCW:Buffer Manager Database pages 11356975 65792
MSSQL$ServerNameC3SCW:Buffer Manager Checkpoint pages/sec 1053996662 272696576
MSSQL$ServerNameC3SCW:Buffer Manager Page life expectancy 4233 65792
MSSQL$ServerNameC3SCW:Buffer Node Database pages 003 2975519 65792
MSSQL$ServerNameC3SCW:Buffer Node Page life expectancy 003 4892 65792
MSSQL$ServerNameC3SCW:Buffer Node Database pages 002 2938151 65792
MSSQL$ServerNameC3SCW:Buffer Node Page life expectancy 002 4051 65792
MSSQL$ServerNameC3SCW:Buffer Node Database pages 001 3002872 65792
MSSQL$ServerNameC3SCW:Buffer Node Page life expectancy 001 4052 65792
MSSQL$ServerNameC3SCW:Buffer Node Database pages 000 2440433 65792
MSSQL$ServerNameC3SCW:Buffer Node Page life expectancy 000 4052 65792
MSSQL$ServerNameC3SCW:Memory Manager Database Cache Memory (KB) 90855800 65792
MSSQL$ServerNameC3SCW:Memory Manager Free Memory (KB) 286672 65792
MSSQL$ServerNameC3SCW:Memory Manager Memory Grants Pending 0 65792
MSSQL$ServerNameC3SCW:Memory Manager Total Server Memory (KB) 104857608 65792
MSSQL$ServerNameC3SCW:Memory Node Database Node Memory (KB) 003 23804152 65792
MSSQL$ServerNameC3SCW:Memory Node Free Node Memory (KB) 003 73256 65792
MSSQL$ServerNameC3SCW:Memory Node Database Node Memory (KB) 002 23505208 65792
MSSQL$ServerNameC3SCW:Memory Node Free Node Memory (KB) 002 76392 65792
MSSQL$ServerNameC3SCW:Memory Node Database Node Memory (KB) 001 24022976 65792
MSSQL$ServerNameC3SCW:Memory Node Free Node Memory (KB) 001 77504 65792
MSSQL$ServerNameC3SCW:Memory Node Database Node Memory (KB) 000 19523464 65792
MSSQL$ServerNameC3SCW:Memory Node Free Node Memory (KB) 000 59520 65792

とクエリ後のカウンター

object_name counter_name instance_name cntr_value cntr_type
MSSQL$ ServerNameC3SCW:Buffer Manager Database pages 11355652 65792
MSSQL$ ServerNameC3SCW:Buffer Manager Checkpoint pages/sec 1054000434 272696576
MSSQL$ ServerNameC3SCW:Buffer Manager Page life expectancy 310 65792
MSSQL$ ServerNameC3SCW:Buffer Node Database pages 003 2980418 65792
MSSQL$ ServerNameC3SCW:Buffer Node Page life expectancy 003 5417 65792
MSSQL$ ServerNameC3SCW:Buffer Node Database pages 002 2946298 65792
MSSQL$ ServerNameC3SCW:Buffer Node Page life expectancy 002 4591 65792
MSSQL$ ServerNameC3SCW:Buffer Node Database pages 001 2995850 65792
MSSQL$ ServerNameC3SCW:Buffer Node Page life expectancy 001 155 65792
MSSQL$ ServerNameC3SCW:Buffer Node Database pages 000 2433086 65792
MSSQL$ ServerNameC3SCW:Buffer Node Page life expectancy 000 165 65792
MSSQL$ ServerNameC3SCW:Memory Manager Database Cache Memory (KB) 90845216 65792
MSSQL$ ServerNameC3SCW:Memory Manager Free Memory (KB) 219240 65792
MSSQL$ ServerNameC3SCW:Memory Manager Memory Grants Pending 0 65792
MSSQL$ ServerNameC3SCW:Memory Manager Total Server Memory (KB) 104857608 65792
MSSQL$ ServerNameC3SCW:Memory Node Database Node Memory (KB) 003 23843344 65792
MSSQL$ ServerNameC3SCW:Memory Node Free Node Memory (KB) 003 51864 65792
MSSQL$ ServerNameC3SCW:Memory Node Database Node Memory (KB) 002 23570384 65792
MSSQL$ ServerNameC3SCW:Memory Node Free Node Memory (KB) 002 59680 65792
MSSQL$ ServerNameC3SCW:Memory Node Database Node Memory (KB) 001 23966800 65792
MSSQL$ ServerNameC3SCW:Memory Node Free Node Memory (KB) 001 58144 65792
MSSQL$ ServerNameC3SCW:Memory Node Database Node Memory (KB) 000 19464688 65792
MSSQL$ ServerNameC3SCW:Memory Node Free Node Memory (KB) 000 49552 65792
Target Server Memory (KB) MSSQL$GKKTSQLC3SCW:Memory Manager 104857608 65792

SELECT @@versionは次を返します：

 Microsoft SQL Server 2012-11.0.5058.0（X64）
 2014年5月14日18:34:29 
 Copyright（c）Microsoft Corporation 
 Enterprise Edition：Core-ベースのライセンス（64ビット）on Windows NT 6.3（Build 9600：）

実行計画では、クラスター化インデックスシークのコストが100％、並べ替え、ハッシュマッチングのコストが0％であることがわかります。欠落しているインデックスに関するヒントがありますが、29 mln行のテーブルの場合、5列を超える追加のインデックスになります。

sql-serversql-server-2012page-life-expectancy
3
whd

クエリがPLEを削除することは珍しいことではありません。クエリは任意の量のメモリを消費する可能性があります。これは通常、次の2つの理由で発生します。

  1. 並べ替えとハッシュのための作業メモリ。
  2. 読み取られたデータでバッファプールを満たすこと。

クエリの実行中にそれぞれのDMVからの未解決のメモリ許可を監視することで、（1）が発生していることを証明できます。クエリが大量のメモリを消費する場合は、そのメモリ量を必要としない実行プランを実現する必要があります。リソースガバナーを使用して、消費されるメモリを制限することもできます。

問題（2）は、クエリが読み取るデータを少なくすることで改善できます。ここでは、where句をサポートするように設定されたキー列と、選択した列をカバーするインクルード列を使用してインデックスを作成します。 DATA_COMPRESSION。

通常、「ページの不評」が原因で、巨大なスキャンによってバッファプールが破壊されることはありません。新しく読み込まれた大きなスキャンのページは、メモリを解放する必要があるときに追い出される最後のページではなく、最初のページになるように処理されます。正確なルールは思い出せませんが、通常、SQL Serverはバッファプールを強制終了せずに巨大なデータセットをスキャンできます。

したがって、実験としてそのインデックスを作成し（可能な場合）、クエリメモリの許可を確認します。

5
usr

したがって、この質問に答えるための情報は実際には不十分です。結果テーブルの大きさは？クエリプランはどこにありますか？

私はそれが非常に大きいと想定しています...したがって、このクエリを実行すると、以前にキャッシュされていなかった大量のデータを取り込み、PLEが約70に低下しているため、PLEが急落します。つまり、約70秒後に、あなたがキャッシュに持ってきたもののすべてではないとしても、ほとんどが古くなっています。そのため、15分後にもう一度実行すると、その大量のデータがキャッシュに戻され、PLEが再び急降下します。これはバグではなく、SQL Serverの動作方法です。

さらに、PLEは4つのNUMAノードのうち2つだけで急落していることがわかります。

3
Chad Mattox