SQL Server 2008でメモリ不足の障害の根本原因を見つけるにはどうすればよいですか？
私がパフォーマンスを監視しているサーバーの1つが、Resource-Exhaustion-Detectorから次の警告をスローし始めました。
Windowsは、仮想メモリの不足状態を正常に診断しました。次のプログラムが最も多くの仮想メモリを消費しました：sqlservr.exe（1560）は14960812032バイトを消費し、ReportingServicesService.exe（1936）は506359808バイトを消費し、w3wp.exe（7376）は273764352バイトを消費しました。
SystemCommitLimit 38068215808 SystemCommitCharge 37800669184 ProcessCommitCharge 16727490560 PagedPoolUsage 359088128 PhysicalMemorySize 17098584064 PhysicalMemoryUsage 16881131520 NonPagedPoolUsage 221425664プロセス48
このサーバーは、MSSQL 2008 R2を実行するWindows Server 2008であり、16GBのRAMと24個のプロセッサーを備えています。 SQLと、SQL forDataにアクセスするWebサービスを実行します。
引用に含めた数値は、イベントビューアの詳細セクションからのものです。根本的な原因を特定できませんでした。 SQLが機能するには大量のメモリが必要であることをすでに知っていて、当時は大量のメモリを使用していましたが、上限を14000MBに設定しました。
SQLは、Resource-Exhaustion-Detectorの警告に加えてメモリ不足エラーを受け取り始めました。
これの根本原因を見つけるための最良のアプローチは何でしょうか？ログに異常なものを見たことはありません。このエラーが数時間繰り返された後、メモリが最終的に使い果たされ、サービスが再起動するまでサービスが失敗し始めました。
SQLは、プレッシャーがかかったときにメモリの一部を放棄するほど賢くないのでしょうか。ページファイル（仮想メモリ）は20GBで、SQLは16GBの物理メモリしか使用していませんでした。残りの仮想メモリは何でいっぱいになりましたか？ SQLは実際にそのページファイルのすべてを使用していましたか？
メモリリークを探す必要がありますか？ログファイルの増加？
サーバーで最も使用される.mdfは、毎日約100MB増加します。ログファイルは、現在40GBであるように、一度に3GBずつ増加しています。
通常、メモリに負荷がかかっている場合は、サーバーがクラッシュするほどには至っていません。それは通常、圧力がなくなるまで痛々しく遅く実行されます。
この問題の発生を効果的に阻止する方法はありますか？
これを適切に診断するには、さらに情報が必要です。
SQL Serverは、他のWindowsプロセスと同じです。仮想アドレス空間は物理RAMよりはるかに大きくなる可能性があります。メモリマップファイルを使用している場合は、RAM +ページングファイルよりも大きくなることもあります。
SQLサーバーのチューニングパラメーターは、 'x' MBを超えて使用しないように指示する方法です。ボックス上の他のすべてのサービスの最大コミット料金を確認し、これを物理的なRAMの数値から差し引いて、残りをSQL Serverに与えます。私が知る限り、メモリキャップはRDBMSにのみ適用され、関連するSQLサーバーサービスの管理には適用されません。
したがって、残りのプロセスについては、さらに多くの数値が必要になります。たとえば、IISワーカープロセスが273MBを消費していますが、ワーカープロセスは1つしかありませんか？ウイルス対策ソフトウェアまたはバックアップソフトウェアがインストールされていますか？
WSRMを使用して何が起こっているかをプロファイリングしてから、メモリキャップの適用を検討できます。または、RAMを追加することをお勧めします。
メモリの行き先をグラフィカルに表示するには、MicrosoftSysInternalsのRAMMapユーティリティに注目してください。
この問題の発生を効果的に阻止する方法はありますか？
グリブの答えは、より多くのメモリを購入することを提案することです。それはあなたの問題を解決しないかもしれませんが、それはおそらく害はないでしょう。
SQL Serverはメモリが好きです。 SQL Serverは、データベースまたはデータベースのチャンクをメモリにキャッシュして、アクセスを高速化することを好みます。現在メモリに何があるかを確認したい場合は、DMVからその情報を取得できます。 http://www.mssqltips.com/sqlservertip/2393/determine-sql-server-memory-use- by-database-and-object / 。私の同僚の1人は、製品のDBのデータベースサイズがサーバーのメモリのサイズを超えないようにするというベンダーの推奨を受け取ったことがあります。これはほとんどの人にとって実用的ではありませんが、問い合わせの多い10 TBのデータベースを16 GBのRAMで提供しようとすると、問題になる可能性があります。
サーバーでsp_blitzを実行してみてください。これは、サーバーに問題がないかどうかをチェックするストアドプロシージャです。 http://www.brentozar.com/blitz/
Perfmonも試してください： http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/
これは原因を突き止めるのに役立ちます。
メモリコミットサイズの断続的なスパイクを処理できるようにするには、ページファイルのサイズを増やす必要がある場合があります。この問題は、Azureコンピューティングで頻繁に発生します。メモリを集中的に使用するアプリの場合、Pagefileのデフォルトの設定が低すぎるためです。
詳しくはこちらをご覧ください： http://mvolo.com/low-pagefile-can-cause-503-service-unavailable-on-Azure-web-roles/
SQLインスタンスが現在よりも多くのメモリを必要とする場合、これは問題を解決しませんが、一時的なスパイクをよりよく乗り切るのに役立つ可能性があります。