バッファサイズの変更？
実動データベースで、ページの平均余命（PLE）が大きく変動している問題が発生しています。 （ランダムにゼロにクラッシュします。）
私はPLEの問題を調査していて、VMWareの問題を指摘しているように見える何かを見つけましたが、データの権利を使用しているのかどうかわかりません。バッファ/キャッシュページを失っているようです。
私はこのクエリを使用しています：
SELECT COUNT(*) AS cached_pages_count,
CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE DB_NAME(database_id)
END AS database_name
FROM sys.dm_os_buffer_descriptors
GROUP BY DB_NAME(database_id), database_id
ORDER BY cached_pages_count DESC;
（見つかりました ここ ）
PLEがクラッシュする前後の結果（カウント）を合計しています。例は、前に1,097,820、後に131,394です。だから私は966,426ページを「失う」ようです。
私の推測では、すべての仮想マシンのハードウェアに負荷がかかっているため、しばらくの間、サーバーから一部のメモリがランダムにスワップアウトされます。 （これは単なる推測です。）それが発生すると、すべてのページが失われるため、PLEは急落します。
だから、私はsys.dm_os_buffer_descriptors正しく表示しますか？私が読んだものから、常に使用済みのバッファ/キャッシュされたページが表示されます。したがって、それが空の場合（または大幅に削減された場合）、メモリがなくなったか、空です。 （この結論を確認する方法が欲しいです。）
それとも、なぜカウントがそれほど下がるのかについて別の説明がありますか？
行の下の情報は、OPのコメントから追加されました
システム管理者がVMを管理します。私はこのデータで彼らに行く前に私のクエリを理解したいと思っています。データベースの観点から、PLEクラッシュのタイミングはランダムに見えます。 （PLEクラッシュ中に、再インデックスやその他の高パフォーマンスの問題は発生しません）
大量の作業を行って、それが作業負荷に関連しているかどうかを確認しました。また、パフォーマンスの低いクエリが1つありますが、すべてのキャッシュを使い切るには不十分です。バッファカウントが減少しても、サーバー上での再構築やその他の非日常的なユーザーアクティビティはありません。そして、そうであったとしても、それが上記の私のクエリで使用されていることはわかりませんか？ （SQL Serverアクションの場合、カウントが異なるだけでカウントは変わらないのですか？）
VMWare設定にアクセスできません。調査結果を理解する前に、調査結果をよりよく理解したいと考えていました。この質問の要点は、最初にビューを正しく使用していたことを確認することでした。
コメントチェーンの最後：
私はPLEの問題が私にバッファページの損失の問題を引き起こしたと言っていました。 PLEを取得するために使用していたクエリは、ページが失われているため、低いPLEを示します。だから、それらにあったものがなくなっていました。メモリの量が減ったので、それは誤った読みでした。
ここに私の@ @バージョンがあります：
Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64)
Dec 28 2012 20:23:12
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
Q：非常に変動するPage Life Expectancy（PLE）問題が発生している本番データベースがあります。 （ランダムにゼロにクラッシュします。）
Select @@Versionの出力内容についてお伺いします。 SPとSQL Serverにパッチが適用されているCUレベルです。これを質問している理由は、SQl Server 2012にバグがあり、観察しているようにPLEが急降下したためです。Thsバグが修正されました SQL Server 2012 SP1 CU4 。または、安全のために、CU4を使用する代わりに SQL Server 2012 SP2 を適用することをお勧めします
PLEが高いアクティビティを持つシステムで変動するのは、そのsometime正常です。実際、これはPLEコードがSQL Serverでどのように機能するかによります。しかし、そのゼロへの急降下が頻繁に発生するという事実は、あなたが上記のバグにぶつかったのではないかと私に思わせます。
Microsoftバグ修正の詳細に従って
SQL Server 2012でパフォーマンスが低下することがあります。SQLServerパフォーマンスモニターツールを確認すると、次のように表示されます。
•SQLServer：Buffer Manager\Pageの平均余命パフォーマンスカウンター値の急激な減少。この問題が発生すると、カウンターは0に近くなります。
システム上のPLEは、バッファープールの変動性の尺度であり、SQL Serverで行われるI/Oアクティビティの量の尺度でもあります。 MSDNによると
ページの平均余命-ページが参照なしでバッファプールに留まる秒数を示します
この定義は不完全だと私を信じてください。それは完全な定義ではない時間の形でそれを記述します。これはサーバーのI/Oアクティビティの測定値であることにいつも気づきました。 I/Oアクティビティが大きいほど、BPoolの揮発性が高くなり、PLEが変動します。
Q：私の推測では、すべての仮想マシンのハードウェアに負荷がかかっているため、しばらくの間、サーバーから一部のメモリがランダムにスワップアウトされます。
これが事実であり、SQL Serverがそのような問題の被害を受けないようにしたい場合は、SQl Serverサービスアカウントに Locked Pages in Memory Privielge（LPIM） があることを確認する必要があります。これにより、OSがSQL Serverのメモリを強制的にページアウトすることはありません。 SQLサービスを実行しているアカウントがデフォルトでローカルシステムである場合、SQL ServerはSQL Server 2012でこの権限を持ちます。
注：
これは回避策です。ここでの解決策は、stressにVM machine。を引き起こしている原因を見つけることです。これを修正する必要があります。感じたら Wmwareバルーニング が問題です。 RAMMAPツール を使用して、
Locked Driverによって消費されるメモリを追跡できます。RAMMAPツールで、VMwareバルーニングの兆候を示すロックされたドライバーが巨大なメモリを使用していることがわかります。チームの助けを借りて、SQL Serverが実行されている仮想マシンのバルーニングを構成/無効化するLPIMを指定する前に、 最大サーバーメモリの最適値 を設定し、OSが効率的に実行するための十分なメモリを残しておく必要があります。
上記の2つのポイントに従わない場合、およびLPIMが原因でOSに深刻なメモリ不足が発生した場合、SQL Serverにメモリを強制的に解放させることができないため、OSプロセスがページアウトされ（LPIMによりロック/ページング不可）、その結果、速度が大幅に低下します。 OSプロセスの。
Q：では、sys.dm_os_buffer_descriptorsビューを正しく使用していますか？私が読んだものから、それは常に使用されたバッファ/キャッシュされたページを示しています。したがって、それが空の場合（または大幅に削減された場合）、メモリがなくなったか、空です。 （この結論を確認する方法が欲しいです。）
既に述べたように、バッファー記述子は、現在SQL Serverバッファープールにあるすべてのデータページに関する情報を返します。 IMHOバッファページare affected by I/O activity on server and thus indirectly related to PLE。大量のページをディスクからメモリにフェッチする要求がある場合、新しいページをメモリに取り込むためにバッファプールにスペースを作成する必要があるとSQL Serverがデータページをディスクにフラッシュし、その結果、特定のデータベースのメモリに存在するデータページ。
したがって、sys.dm_os_buffer_descriptorsを介して表示されている内容は正しくありますが、バッファ記述子DMVを使用してサーバー上のPLEを測定することはnot suggestとします。これは正しいアプローチではありません。
これはグループの努力であり、私の役割は主にキュレーターです。
あなたが見ている結果を見ることができる理由はたくさんあります。
Zane 彼がコメントしたとき、いくつかの潜在的な原因を提供しました：
VMメモリでオーバーコミットされていますか？この時間中に他のアクティビティがピークに達しているため、ウィンドウはSQLサーバーからメモリを取り戻す必要がありますか？これは高負荷時に発生しますか？他にどのようなプロセスが実行されていますか？機械？
Tom V も彼のコメントでいくつかの潜在的な原因を提供しました：
その時点でインデックスのメンテナンスを行っていますか？ VMwareの問題だと思われる場合、VMwareコンソールにアクセスできますか？もしそうなら、バルーニングステータスは何ですか？ MCTLSZはesxtopで何と言っていますか？
swasheck ワークロードの調査における重要性についても言及しました：
正しく発生したVMwareの影響に加えて、ワークロードについても何も伝えていません。つまり、インデックスの再構築、ページへの書き込みなどです。
VM /メモリのプレッシャーは疑わしいと思われるため、システム管理者にいくつかの基本的な質問をする必要があります。
非挑発的な方法で尋ねるいくつかの提案された質問は次のとおりです。
- VMに固定メモリまたは動的メモリを割り当てているかどうかをシステム管理者に尋ねます。 - Aaron Bertrand
- それらが[メモリ]を膨らませたり、過剰に割り当てたりしている場合。 - ゼーン
また、PLEとメモリ内のバッファページの数がわかりにくいようです。
swasheck をはじめとする Max Vernon を含む数人の人がこの問題に言及しました。
@swasheckが言ったように、あなたが質問で参照する数字はPLEではありません。これらは、メモリ内のバッファページの数です。 PLEは「Page Life Expectancy」であり、メモリ内のバッファページ数を変更せずに増減できます。 PLEは、平均データページがメモリに留まる時間の長さです。メモリ内に割り当てられたページ数を失うことなく、これが数万から0まで変動するサーバーを見てきました。 PLEが本当に低い場合は、バッファページの数が予期せず減少するのとはまったく異なる問題を示しています。
ゼーン 彼が言ったときのPLEの役割を明確にしました：
ここでの使用PLEの問題は、バッファプールで使用可能なメモリの実際の損失を示していないことです。それは、新しいデータのためにページがフラッシュされる頻度のターンアラウンドの測定に関するものです。
メモリの問題をチェックアウトするためのより良いオプション
Max Vernon 次のクエリを使用することをお勧めします：
SELECT * FROM sys.dm_os_sys_memory ORDER BY system_memory_state_desc
Kin は次のことも提案しています：
System_health_sessionは、メモリ不足の通知による内部または外部のメモリプレッシャーであるかどうかを明確に示します。
これは、バックグラウンドで実行できる拡張イベントです パフォーマンスに影響を与えることなく 。