バッファの問題をデバッグするにはどうすればいいですか?
-
29-09-2020 - |
質問
私は、「Microsoft SQL Server 2012(SP1) - 11.0.3128.0(X64)」を持っています。
私は私のサーバーで毎分走っています(この問題を追跡するため):
SELECT @ple = CAST([cntr_value] AS VARCHAR(20))
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Manager%'
AND [counter_name] = 'Page life expectancy'
SELECT @usedBufferPages = CAST(COUNT(*) /128 AS VARCHAR(20))
FROM sys.dm_os_buffer_descriptors
DECLARE @StartDate VARCHAR(8) = Convert(VARCHAR(8), GETDATE(), 14)
RAISERROR ('%s. PLE at %s and Used Buffers at %s at %s ', 0,
1,@runCountString ,@ple, @usedBufferPages, @StartDate) WITH NOWAIT
.
これはいくつかの出力です:
16. PLE at 858 and Used Buffers at 7290 at 09:51:42 17. PLE at 918 and Used Buffers at 7342 at 09:52:42 18. PLE at 978 and Used Buffers at 7408 at 09:53:43 19. PLE at 1039 and Used Buffers at 7547 at 09:54:43 20. PLE at 1100 and Used Buffers at 7697 at 09:55:44 21. PLE at 1160 and Used Buffers at 7901 at 09:56:45 22. PLE at 1221 and Used Buffers at 7961 at 09:57:46 23. PLE at 1282 and Used Buffers at 8012 at 09:58:46 24. PLE at 11 and Used Buffers at 313 at 09:59:46 25. PLE at 31 and Used Buffers at 966 at 10:00:46 26. PLE at 90 and Used Buffers at 1580 at 10:01:47 27. PLE at 151 and Used Buffers at 3072 at 10:02:47 28. PLE at 211 and Used Buffers at 3152 at 10:03:47 29. PLE at 271 and Used Buffers at 3729 at 10:04:47.
項目#24 SQL Serverは、PLEが 1,282から11 に通知します。 SQL Serverはまた、使用されているバッファーが 8,012から313 へのアクセスからなることを報告します。
最初に実行不良のクエリを探していて、私は修正された数を見つけました(問題には影響しませんでした)。しかし、私はPLE / BUFFFERの問題がある時代に相関する問題のクエリを見つけていません。また、実行不良のクエリが不十分であれば、バッファはそのクエリのデータでいっぱい、空き/欠落/エラー済みではありません。
次に、これが起こったときに仮想マシンがそのメモリが制限されていたと考えました。しかし、私は私のシステム管理者に尋ねました、そして、彼は私にメモリが動的ではなく、または共有されていないことを私に保証します。 (割り当てられているのは、常に取得します。)も、10分ごとにこのスクリプトを実行し、PLEレポートが50以下の場合は:
SELECT * FROM sys.dm_os_sys_memory
.
と、PLE /バッファが高く、低いときに同じ/類似の値を報告します。完全性のために、ここでは上記の#24の前後の値の例があります。
total_physical_memory_kb available_physical_memory_kb total_page_file_kb available_page_file_kb system_cache_kb kernel_paged_pool_kb kernel_nonpaged_pool_kb system_high_memory_signal_state system_low_memory_signal_state system_memory_state_desc 20970996 4758672 24378868 7929404 4844160 686076 182752 1 0 Available physical memory is high 20970996 4743468 24378868 7892632 4845000 686580 182688 1 0 Available physical memory is high.
システムヘルスセッションをチェックし、それに関連しないものを示していません。 (それが偽装は偽装です、そして彼らの時代はPLE /バッファーが問題を示す時代と相関しない。
これが発生する頻度を追跡し、パターンを見たり、任意のジョブや予定アクティビティに接続することはできません。
これは21時間かけてPLEとバッファを示すグラフです:
だから私は急に眠っています。問題の中核は、PLEではなくバッファーです。 (私は、すべてのバッファがどういうわけか消去しているので、PLEがローの誤った報告を受けることになっていると思います。)
しかし、これが起こる可能性があるように考えられない。または次の方法。
この問題があるかもしれないもののチェックや提案のための追加のことについてのアドバイスを愛します。
コメントの質問からの更新:
SO、サーバのメモリの量は? VMには20 GBのメモリがあります。
Max Serverメモリとは何ですか?
name value value_in_use description max server memory (MB) 13000 13000 Maximum size of server memory (MB) min server memory (MB) 0 16 Minimum size of server memory (MB).
注:今すぐこれで読む少し読むことができ、これらの設定が私のサーバーに間違っているようです。
データベースの大きさは?このサーバー上では2つのトランザクションデータベースが実行されています(サーバーを隔離するプロセスにあります)。サイズは383 GBと378 GBです。
そのサーバー上でどのようなアプリケーションとサービスが実行されているのでしょうか。このサーバーは私のアプリケーションのデータをホストします。それを打つことは他にもありません。 (私はレポート用の複製操作データストアを持っています。
VMテクノロジ VMウェアとは何ですか。
は、同様のリソース割り当てのあるVMSのみをホストしているホスト上で実行されているこのVMですか?私たちの会社には多くのVMがあります。さまざまなサイズのすべて。これは最も大きいものの1つです。
あなたのシステム管理者が彼を信じる必要なしにあなたの記憶割り当てについてあなたに言っていることを確認することができますか?私はできません。私はそれらのツールにアクセスできません。
(私の経験では、システム管理者は降圧を渡すことがたくさんあることを言うでしょう。その感情を理解する。
そのパターンは確かに厳しい記憶圧力私が同意するように見える。私はSQLがメモリ圧力を感じていることを証明する何かを見つけることを望んでいました。だから私はそれをより多くの研究のためにシステム管理者に送り返すことができます。
待機時間統計
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S ---------------------- ----------- ----------- --------- ---------- ------------ ---------- --------- --------- PAGEIOLATCH_SH 16250.10 16219.14 30.96 2171649 29.59 0.0075 0.0075 0.0000 CXPACKET 14214.03 13238.56 975.47 1187935 25.88 0.0120 0.0111 0.0008 PAGEIOLATCH_EX 6814.59 6806.21 8.38 638725 12.41 0.0107 0.0107 0.0000 WRITELOG 5157.42 4873.44 283.98 3588476 9.39 0.0014 0.0014 0.0001 BACKUPIO 2569.51 2538.12 31.39 1704119 4.68 0.0015 0.0015 0.0000 LCK_M_IX 2477.15 2477.10 0.05 113 4.51 21.9217 21.9213 0.0004 ASYNC_IO_COMPLETION 2079.99 2079.66 0.33 836 3.79 2.4880 2.4876 0.0004 BACKUPBUFFER 1807.75 1759.11 48.64 380189 3.29 0.0048 0.0046 0.0001 IO_COMPLETION 986.23 985.84 0.39 116112 1.80 0.0085 0.0085 0.0000.
解決
問題はSQL Server 2012のバグによるものです.THSバグは SQL Server 2012 SP1 CU4 。またはより安全にしてください。SP2 CU 4に行く代わりに。
マイクロソフトのバグ修正詳細
SQL Server 2012ではパフォーマンスが低下する可能性があります。 SQL Server Performance Monitor Tools、次のようになります。
•SQLServerの急激な縮小:Buffer Manager \ Page Life Pime パフォーマンスカウンタ値この問題が発生すると、カウンタはです 0近くの
他のヒント
あなたのバッファプールは唯一の13Gb で、データベースは383 GBと378 GBです。これはOLTPであると分類されている - 小さなトランザクションが頻繁に実行されています。
上記の状況、私が想像する必要があるならば、以下のようなものです:
SQL Serverの情報を理解する必要があります。
SQL Serverは、メモリキャッシュと呼ばれる構造体に情報をメモリに格納します。 キャッシュ内の情報は、データ、インデックスエントリ、コンパイル済み手順プラン、およびさまざまな種類のSQLサーバー情報です。情報の再作成を避けるために、メモリキャッシュが長く保持されます。できるだけ安すぎる場合、または新しい情報にメモリスペースが必要な場合は、通常、キャッシュから削除されています。古い情報を削除するプロセスはメモリスイープと呼ばれます。
メモリ掃引は頻繁なアクティビティですが、連続していません。
データベースサイズと不適切なバッファプールの量の純粋な量のメモリ飢餓を確実にしています。参照してください - 例えば理想的なメモリを決定する方法?
ここでデバッグすることはほとんどありません - あなたはメモリを追加する必要があります。800 GBのデータを13 GBのメモリにフィットさせようとすることは、バックパックで停止しようとするようなものです。
実行中のクエリで近づく。データベース上のメモリ使用量だけでは、通常、物事を改善するためのメトリックが粗すぎます。クエリに影響を与えることができないと仮定すると、メモリ使用量に影響を与えているものを理解する価値があります。たとえば、バッチプロセスは、大規模なテーブル上のすべてのデータを照会することによって、1回のヒットのすべてのバッファスペースを実行して使用することができます。
特に、サーバー上のキャッシュを効果的にフラッシュできるため、フルテーブルスキャンを引き起こす不足しているインデックスを探します。SQL Serverには、リアルタイムで監視できるアナライザーツールの優れたセットがあります。
データベーススキーマの変更を提案しているのではなく、探していないことの1つは過度に大きなVARCHARフィールドです。