質問

私は、「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と21時間以上バッファ

だから私は急に眠っています。問題の中核は、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   
.

役に立ちましたか?

解決

このSEスレッドとOPによって確認された。

問題は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であると分類されている - 小さなトランザクションが頻繁に実行されています。

上記の状況、私が想像する必要があるならば、以下のようなものです:

 Enter Imageの説明がここに (出典:Google Photos)

SQL Serverの情報を理解する必要があります。

SQL Serverは、メモリキャッシュと呼ばれる構造体に情報をメモリに格納します。 キャッシュ内の情報は、データ、インデックスエントリ、コンパイル済み手順プラン、およびさまざまな種類のSQLサーバー情報です。情報の再作成を避けるために、メモリキャッシュが長く保持されます。できるだけ安すぎる場合、または新しい情報にメモリスペースが必要な場合は、通常、キャッシュから削除されています。古い情報を削除するプロセスはメモリスイープと呼ばれます。メモリ掃引は頻繁なアクティビティですが、連続していません。

データベースサイズと不適切なバッファプールの量の純粋な量のメモリ飢餓を確実にしています。参照してください - 例えば理想的なメモリを決定する方法?

collect 待機してください統計パフォーマンスを確認する無駄なバッファプールメモリから発生する問題

推奨事項:

サーバインスタンスにメモリを追加し、適切なメモリを持つ異なるVMに2つのデータベースを分離します。

ここでデバッグすることはほとんどありません - あなたはメモリを追加する必要があります。800 GBのデータを13 GBのメモリにフィットさせようとすることは、バックパックで停止しようとするようなものです。

実行中のクエリで近づく。データベース上のメモリ使用量だけでは、通常、物事を改善するためのメトリックが粗すぎます。クエリに影響を与えることができないと仮定すると、メモリ使用量に影響を与えているものを理解する価値があります。たとえば、バッチプロセスは、大規模なテーブル上のすべてのデータを照会することによって、1回のヒットのすべてのバッファスペースを実行して使用することができます。

特に、サーバー上のキャッシュを効果的にフラッシュできるため、フルテーブルスキャンを引き起こす不足しているインデックスを探します。

SQL Serverには、リアルタイムで監視できるアナライザーツールの優れたセットがあります。

データベーススキーマの変更を提案しているのではなく、探していないことの1つは過度に大きなVARCHARフィールドです。

ライセンス: CC-BY-SA帰属
所属していません dba.stackexchange
scroll top