SQL Server 2005から2012への移行後のパフォーマンスの問題
先週の金曜日、SQL Serverインスタンスを2005 Enterprise Editionから、SQL Server 2012 Enterprise Editionがインストールされた新しいWindows Server 2012サーバーに移行しました。それ以来、ユーザーはアプリケーションのパフォーマンスに不満を持ち始めています。
サーバーに関する情報は次のとおりです。
- VMWare 5.5上の仮想サーバー
- 4 vCPUおよび24 Gb RAM。以前の構成では10 Gbが必要でしたが、tempdbデータベースは私が設定したものよりも小さかった（ほぼ6Gb）
- 最大メモリターゲットを22 Gbに設定しました。tempdbは完全にバッファプールにあります
- 移行後（データベースミラーリングを使用して実行）、統計の更新、インデックスの再構築、およびその他のメンテナンスコマンドを実行しました
どこに答えがあるかわかりません。 SQL Serverインスタンス以外のすべてが同じである場合（VM、ディスクなど）、問題はSQL Serverの構成にありますが、どこにありますか？いくつかの変更を試しましたが、どれも役に立たなかったようです。
あなたはなにか考えはありますか？
コメントからの追加情報
- Sp_Blitzを実行したところ、いくつかの情報が得られましたが、SQL 2005の新機能はありません（たとえば、ストレージが遅い）。
- メモリ消費量（20Gb +）は、主にtempdb（6Gb）が原因であり、残りは主にアプリケーションデータベースによって使用されます。
- PLEが流れ、時には150に下がる。1日の初めに、ほとんどのデータがキャッシュからなくなる
- 以前のサーバーでの最大メモリ設定は10Gbでした
- Idera診断マネージャーを使用します
- 最大サーバーメモリは、前のサーバーの値の2倍に設定されています。
- ページ寿命が少なくとも1日2回で150未満に下がる
sp_BlitzIndex分析
私はsp_BlitzIndexで分析を開始しましたが、不十分に記述されたコードに加えて、次のことを示しています。
アグレッシブインデックス：合計ロック待機時間> 5分（行+ページ）
dbo.TABLE1.PK_TABLE1 (1): Row lock waits: 3,591; total duration: 10 minutes; avg duration: 0 seconds; Page lock waits: 23; total duration: 15 seconds; avg duration: 0 seconds; Lock escalation attempts: 510,489; Actual Escalations: 1. dbo.TABLE1.I_TABLE1_CNTTYPE_CATEGORY_IS_CURRENT (85): Row lock waits: 155; total duration: 48 seconds; avg duration: 0 seconds; Page lock waits: 129; total duration: 8 minutes; avg duration: 4 seconds; Lock escalation attempts: 29,423; Actual Escalations: 4,951.
追加のインデックスを作成するだけで、その現象にいくつかの変更が加えられますか？
sp_configure
要求に応じてsp_configureの出力を比較しました。違いは次のとおりです。
Config Old New
Blocked process threshold 0 120
Maximum Degree of parallelism 0 4
Maximum Memory (MB) 10240 22000
電源オプションはすでに高性能です。次のコマンドを使用して、メモリを10 Gbに戻しました。
CHECKPOINT ;
DBCC DROPCLEANBUFFERS ;
EXEC sys.sp_configure N'max server memory (MB)', N'10240'
GO
RECONFIGURE WITH OVERRIDE
GO
10 GBのRAMで1時間実行した後：最後の違いは、tempdbのサイズが古いサーバーよりも大きく、現在ほとんどのメモリを使用しているため、ページの寿命が490になることはほとんどありません。
Diagnostic Manager CPU統計レポートの分析
CPU統計レポート：
- 500の平均SQLコンパイル
- 120の平均SQL再コンパイル
- 1分あたり最大10回のロック待機、平均5回
- そして主に、平均40のテーブルロックエスカレーションです。
アドホックワークロードサーバーの最適化設定を既に設定しており、最も使用頻度の高いユーザーデータベースの「強制パラメーター化」も設定しています。
これまでのところ、パフォーマンスの改善があると誰も私に言っていません。これは私が取得したデータベースであり、DBAチームによって管理されていなかったため、通常の状態に戻ったかどうかを確認するための背景がありません...
しばらく待って、今のところ大丈夫かどうかを確認します。ご協力ありがとうございます！
最も可能性の高い説明は、統計、インデックスのサイズと密度、および構成設定の変更が原因で、クエリが新しいサーバーで異なる実行プランを使用して実行されていることです。
クエリオプティマイザーの実行プランの選択に最大の影響を与える構成設定は次のとおりです。
新しいインストールではメモリが2倍になったため、これが主な要因である可能性が非常に高いという質問です。直感的に、より多くのメモリが常にパフォーマンスを向上させると期待するかもしれませんが、オプティマイザはネストされたループやインデックスシークの代わりに、より多くのハッシュ、並べ替え、およびスキャンを含む計画を優先し始める可能性があるため、常にそうであるとは限りません。
詳細については、以前の回答を参照してください。
20GBの設定は、通常、起動トレースフラグ2335（その回答で参照）の設定を正当化するのに十分な大きさではありませんが、テストによってのみ、どちらかが証明されます。
潜在的なクイックフィックスとして、max server memory以前の値に戻り、新しいサーバーでリグレッションしたクエリプランを特定し、通常のチューニング方法を使用して根本的な原因を修正します。それが一般的で手荒れしているように聞こえた場合は申し訳ありませんが、実際には、パフォーマンスの低下には非常に多くの考えられる原因があり、最も一般的な原因を特定して修正する方法が確立されています。ここでの私の回答の目標は、システムを2005年の状態に戻すことです。
10 GBのRAMで1時間実行した後：最後の違いは、tempdbのサイズが古いサーバーよりも大きく、現在ほとんどのメモリを使用しているため、ページの寿命が490になることはほとんどありません。
tempdbデータベースは、メモリから溢れることになったソートとハッシュに対応するために、以前に大きくなっている可能性があります。今はそれほど大きくする必要はないかもしれません。 tempdbデータベースは、他のデータベースと同じようにメモリを使用しません。 PLEの「490でほとんど」は、英語の文としては意味がありません。
最大サーバーメモリを10GBに戻すことの重要なポイントは、2005インストールと同様の実行計画を奨励し、それによってパフォーマンスを許容レベルに戻すことでした。それが役に立ったかどうかは言いません。この段階で現地の専門家のサポートが必要になる可能性があります。 Q＆A形式で合理的にできることの限界に達したと思います。