現在、特定のサーバーでの奇妙なメモリ負荷の問題に数か月間取り組んでいます。 SentryOneでの最後のインシデントの様子は次のとおりです。
システムメモリ
SQL Serverメモリ
メモリ構成:
これが奇妙に思われる理由は、それが外部メモリの圧力であった場合、システムメモリの[その他]カテゴリがこの間に大きくなることを期待しているためですが、そうではありません。
この期間中に発生するのは、クエリが最終的に悪い計画を生成し、アプリのパフォーマンスの問題を引き起こすことです。歴史的に、この状況でDBCC FreeProcCacheを実行することでプレッシャーは軽減されましたが、原因はまだわかりません。悪い計画を立てる計画はこの問題の原因というよりは症状だと思いますが、私は間違っているかもしれません。
この問題を解決するために行ったこと:
私は次に何を見るべきかについて完全に迷っています。私たちの建築家は、いくつかのVMメモリの設定をいじる必要があるかもしれないと考えていますが、まだありません。
この奇妙なメモリプレッシャーの問題を潜在的に修正するために何を見ることができますか?
これは間違っているかもしれませんが、とにかくやってみましょう。多分それはあなたに役立つでしょう。
スクリーンショットから、パフォーマンスの問題が発生し始めたときに、ページの平均余命が高まっているように見えます。 PAGEIOLATCH_ *の待機時間が長いクエリがあると思いますか?また、不良プランが生成されており、DBCC FREEPROCCACHEを実行すると問題が一時的に修正されることにも言及しました。私には、パラメータスニッフィングの典型的な症状のように思えます。私はあなたが1つのクエリを持っていると思います、それは間違ったパラメータでコンパイルされたとき、シークの代わりにテーブルスキャンを行い、間違ったインデックスまたはクエリプランの変更の形を使用します。一般に、これは大量のI/Oを必要とし、ストレージサブシステムを飽和させるクエリであるため、キールックアップを実行する単純なクエリでも遅くなります。パフォーマンスに問題がある場合は、それを特定し、その計画のみを削除して確認します。
問題のあるクエリを特定するには、長いPAGEIOLATCH待機があるクエリを調べ、実行プランが速いときに実行プランを比較します。
それを修正するには、クリエイティブになる必要があります。クエリヒントを追加し、実行するたびに強制的に再コンパイルすることを試み、プランガイドを使用することができます。基になるテーブルのインデックスを変更し、問題のあるクエリを書き換えることにも成功しました。現在の問題は、問題の原因を特定することであるため、具体的なアドバイスをすることは困難です。
SQL SQLSkills.comに、Jonathan Kehayiasによるクールな記事のタイトル Wow…SQL Serverのメモリを誤って構成するオンライン計算機! があります。
ジョナサンは彼の記事でこう書いている:
私の一般的な推奨事項は、私の本の計算 SQL Serverのトラブルシューティング:偶発的なDBAのためのガイド を使用することです1 GB RAM for the OS、1 GB for 4 GB of RAM installed from 4–16 GB、そして8 GBごとに1 GB RAM 16 GB RAMの上にインストールこれは過度に技術的な計算ではありませんが、うまく機能しており、通常、「最大サーバーメモリ」を十分に低く設定して、サーバーが安定して信頼性の高いパフォーマンスを発揮できるようにします。
この例を続けて使用する場合は、SQL Serverを81 GBのmax_memory設定で実行するように構成することをお勧めします。
Excelを作成して、次の数式とデータを使用して、SQL Serverの最大メモリ設定の小さなグラフを作成できます。
Excelシートは、HW Memory(A2)列で始まります。
4
2番目の列のExcelの数式OSの予約済み(B2)は次のとおりです。
IF(A2<=16;1 + A2/4;1+4+(A2-16)/8)
SQLメモリ列(C2)は次のようになります。
A1-A2
これにより、次のグラフが生成されます。
ご覧のように、96 GBのRAMがある場合、OS用に15 GBを予約し、SQLメモリ(max_memory)を81 GBに設定する必要があります。
ジョナサンは彼の記事でさらに説明します...
SQL Serverには、SQLOSの組み込みコンポーネントであるResource Monitorがあり、QueryMemoryResourceNotification Windows Server APIを監視して、サーバーのOSレベルのメモリの可用性に関するステータスを取得します。 Windows OSがメモリ不足の場合、リソースモニタースレッドがキャッシュを検出して強制的にキャッシュに入れ、キャッシュのスイープを開始してクリーンアップすることを通知する低メモリ通知を設定します。メモリ使用量を減らし、プロセスがメモリを解放してOSに戻すことができるようにします
OSに十分なメモリがない可能性があり、SQL Server OSからメモリを奪っています。
Max_memory設定を81 GBに少し減らすと、max_memory設定内で実行されないOSおよびその他のSQL Serverコンポーネントに十分なRAMを確保できます。
マイレージは異なる場合があります
夜間のSSISジョブを実行するときに同様の問題が発生しました。SSISのメモリ使用量は、何らかの理由でSentryoneから見えないことがあります。 S1のイベントカレンダーを見て、その時点で実行されているジョブを確認します。