以前のシニアDBAが退職し、私は複数の問題、主に低速(SSMSが開いて長時間かかり、クエリが長時間実行され、SSISジョブ(データウェアハウス)が失敗する)に悩まされているサーバーに気づきました。リンクサーバーへの接続の問題(そのうち150以上))。
5つのスタックされたインスタンスを含むこのサーバーで、多くのことが起こりすぎている可能性があります。新しいシニアDBAがすぐにチームに参加する予定ですが、参加するまでにすべてを整えておくとよいでしょう。
つまり、要点は:
この問題に気付いたとき、サーバーのメモリの94%がSQL Serverに割り当てられていることがわかりました。私は先に進み、過剰にプロビジョニングされた2つのインスタンスからメモリの割り当てを解除することで、それを85%に減らしました。
次に、デフォルトのインスタンスのMAXDOPが4(おそらく6、思い出せない)に設定され、CPUアフィニティ設定が設定されていることに気付きました。これらのCPUは、他のCPUでのアクティビティが最小限である間にペグされました。 CPUを追加する前にこれらの設定が行われていたため、先に進んでアフィニティ設定を削除しました。 5つのインスタンスすべてでMAXDOPを20に設定しました。
現在、私はstillの4つのCPUがペッグされているが、全体的な平均が表示されています。使用率(すべてのCPU全体)は約25%です。
私はSysInternalのProcExp、リソースモニター、およびWindowsパフォーマンスツールキットを使用して問題を観察しましたが、どのプロセスを特定するか、具体的には根本的な原因を特定する方法がわかりません。ここで何が起こっているのかを本当に分離する方法に関する推奨事項/ガイダンスはありますか? (つまり、特定のカウンター/トレース/その他のプログラム)。
[〜#〜] update [〜#〜]、リクエストごと:
システム情報:
Windows Server 2012 R2 Standard
合計64 GBのメモリ
20 CPU
構成:
このインスタンスに割り当てられている24 GBのメモリ
他のインスタンスに割り当てられた26.5 GBのメモリ(合計50.5 GB-78.9%)
並列処理のコストしきい値= 50(すべてのインスタンスで)
未使用のSSASプロセスを無効にしました。
この問題の原因は、ほぼ確実にVMレベルです。運用チームは、20個のCPUだけでなく20個のソケットも持つようにサーバーを構成していました。
仮想サーバーはソケット、コア、CPUを区別しないことをオンラインで読みましたが、構成の変更を要求してから問題は解決しました。さらに、VMwareツールはまったく問題を報告しませんでした。問題が認識されなかったため、VMwareのトラブルシューティングツールも(申し立てにより)利用できませんでした。
つまり、単一のWindowsサーバー上に5つの「スタック」インスタンスがあります。使用可能なソケット/ CPUの数とメモリの量は正確には述べていません。このような場合は、CPU全体の負荷のバランスをとるためにCPUをオーバーラップさせることにしたとしても(各インスタンスの負荷に依存します)、インスタンスごとにアフィニティを設定するのが好きです。
4つを超えるCPUを搭載したインスタンスでは、経験上、明示的なDOP設定を使用できます。過度の並列処理を回避するために、各インスタンスの「並列処理のコストしきい値」を適切な値(50?)に設定することを忘れないでください-あなたの場合、これはさらに重要です。
各インスタンスのフットプリント(SSISの上など)を考慮する必要があるため、「OS用」に残されたメモリはもっと多くなるはずです。 SQL Config MgrでSSASも実行されているかどうかを確認し、それに応じて「最大メモリ」を調整します。デフォルトでは、サーバーメモリ全体の80%(!)
また、SQLサービスアカウントの「メモリ内のページのロック」権限を削除して、OSが呼吸し、その仕事をよりよくできるようにする価値があるかもしれません(ページングした場合、全員が苦しむ!)。また、インスタンスごとに適切な「最小メモリ」を設定することをお勧めします。
各インスタンスでsp_blitzとsp_blitz_firstを実行すると、より差し迫った問題への手っ取り早いヒントが得られると思います。
また、サーバーで問題が発生している日の特定の時間帯を見つけた場合に、そこで実行されている各プロセスの「使用可能なメモリ」や「ワーキングセット」などのいくつかのウィンドウパーモンカウンターを監視することもできます。