メモリのボトルネックオプションを無視するか、受け入れるか、さらに調査させる兆候（ある場合）を探しています。
例：
ページの平均余命：
SELECT [object_name], [counter_name], [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE "%Manager%" AND [counter_name] = "Page life expectancy" 
このとき、現在の環境では、8GBのRAMを搭載したサーバーがあります。管理者に質問します。より多くのメモリのために。これはメモリのボトルネックだと思います。
RAMを使用しているのは別の調査です。
以下のこのメールは、メモリのボトルネックの可能性を特定するのに有効ですか？
SQLServer：バッファキャッシュヒット率を確認する必要があります
その比率がサーバーのメモリ不足よりも95％未満の場合
これがお役に立てば幸いです。
コメント
回答
SQLServer：バッファキャッシュヒット率を確認する必要があります。その比率がサーバーのメモリ不足よりも95％未満の場合は、
バッファの確認を停止します。ヒット率をキャッシュして、メモリの負荷を判断します。これは、SQLServerの先読みメカニズムでは、クエリを満たすのに十分な数のページがバッファプールにすでに存在するため、BCHRがメモリ不足について正確な数値を提供しないためです。メモリが不足している場合でも、BCHRが低下しないことがわかる場合もあります。これらはすべて、 BCHRに関するSQLServerの優れた討論
で説明されています。
投稿したPLE出力は非常に低いようですが、1つのカウンターを使用してゲージメモリ圧力。 PLEは、サーバーでのI / Oアクティビティのより多くの指標です。大量のI / Oアクティビティが原因で、PLEが急落した可能性があります。ターゲットと合計サーバーメモリは同じままです。これは良い兆候です。
Edition upto 2008 R2の場合。以下のカウンターを使用できます
-
SQLServer：Buffer Manager–CheckpointPages / sec：
-
SQLServer：Buffer Manager–Memory Grants保留中：
-
SQLServer：バッファマネージャー-ターゲットサーバーメモリ：
-
SQLServer：バッファマネージャー-サーバーメモリの合計
-
SQLServer：BufferManager–空きページ
-
SQLServer：BufferManager–空きリストのストール/秒
-
SQLServer：BufferManager–ページの期待寿命
SQL Server 2012 onwardsの場合プールカウンターは非推奨であるため、メモリマネージャーカウンターを使用する必要があります
-
SQL Server：メモリマネージャー-ターゲットサーバーメモリ（KB）
-
SQL Server：メモリマネージャー-合計サーバーメモリ（KB）
-
SQL Server：メモリマネージャー-空きメモリ（KB）
-
SQL Server：メモリマネージャー-データベースキャッシュメモリ（KB）
-
SQLServer：バッファマネージャー-空きページ
-
SQLServer：BufferManager–フリーリストストール/秒
-
SQLServer：BufferManager–ページの平均余命
ディスクアクティビティが多い場合は、ディスク関連のカウンターも参照することを忘れないでください。 データコレクターセットを作成し、システムの負荷がピークに達したときに4〜5時間実行してから、質問にデータコレクターのスナップショットを追加します。次に、SQLServerがより多くのメモリを必要とするかどうかを判断できます。
最近のワークロードとOSの要件を考慮すると、個人的には8GのRAMは少し少なくなります。頭の後ろで、常にRAMの増加について考える必要があります。
回答
SQLServer：バッファキャッシュヒット率を確認する必要があります
その比率がサーバーのメモリ不足よりも95％未満の場合
これがお役に立てば幸いです
これは、メモリのボトルネックを確実に判断するのに役立つものではありません。むしろ私が好むのは、重負荷/営業時間中の少なくとも1日は、カウンターの下のデータを収集することです。
Memory – Available MBytes SQLServer: Buffer Manager – Page Life Expectancy SQLServer: Memory Manager – Memory Grants Pending SQLServer: Memory Manager – Target Server Memory SQLServer: Memory Manager – Total Server Memory SQLServer: SQL Statistics – Batch Requests/sec SQLServer: SQL Statistics – Compilations/sec 提案されているようにSQLサーバーのベースラインを作成するのが最適です基本に戻る：本番SQLでのベースラインの取得 必要なperfmonカウンターと問題の待機統計も収集するサーバー。
また、8 GB RAMは、今日の環境ではそれほど適切ではない可能性がありますが、これも状況によって異なります。 インスタンス\インスタンスでホストされているデータベースのサイズとともにシステムの負荷。
Buffer Cache hit ratioに基づいてメモリに関する提案を行わないでください。 。 BCHRに関するSQLServerのすばらしい議論をお読みください。実際、私はこのカウンターに依存していません。 PLEに依存することはできますが、すべてのNUMAノードのPLEを確認する必要があります（ある場合）