データベースユーザーがSQLServerのパフォーマンスが最近低下していると不平を言っている場合は、1つ以上のSQLServerボトルネックの影響を受けている可能性があります。これらのボトルネックはさまざまな理由で発生しますが、メモリ、I / O、またはCPUの問題の結果として頻繁に発生します。
パフォーマンスの問題がSQLServerのボトルネックに起因するのか、別のソースに起因するのかを判断するのは必ずしも簡単ではありませんが、ボトルネックのこれらの一般的な症状を探して、問題の原因を探すのに役立てることができます。
SQLServerのボトルネックの一般的な症状
- SQLServerがプロセッサを占有している
- クエリの実行時間が長くなります
- 過剰なI/O
- メモリ不足のメッセージを示すアプリケーションログ
- ディスクでの極端なアクティビティ
- I/Oあたりの待ち時間が長い
これらの症状の1つまたは複数が突然発生した場合は、システムのどこかにSQLServerのボトルネックがあることを示しています。今、それを見つけるのはあなたの仕事です。
SQLServerのボトルネックの種類
SQL Serverのボトルネックには、メモリ、I / O、CPUの3つの主要なタイプがあります。 DBAがそれぞれの原因、症状、および修正に精通していることが重要です。これにより、DBAはボトルネックをすばやく特定して取り除き、パフォーマンスの低下による影響を最小限に抑えることができます。また、パフォーマンスのボトルネックをすぐに特定するのに役立つ、監視するのに最適なパフォーマンスカウンターをいくつか含めました。
メモリのボトルネック
メモリのボトルネックは通常、メモリリソースが不足しているか、SQLServerのアクティビティが使用可能なメモリを消費していることが原因です。注意すべき症状には、クエリの実行時間の延長、過剰なI / O、アプリケーションログのメモリ不足メッセージ、頻繁なシステムクラッシュなどがあります。
メモリ関連のボトルネックを回避する最善の方法は、クエリオプティマイザを使用して不要または廃止されたクエリを取り除き、ディスクへのトリップを制限するためにバッファキャッシュヒット率と組み合わせてページの平均余命を設定することです。ボトルネックを回避するには遅すぎる場合は、クエリの確認と調整、メモリの再構成、または物理メモリの追加を試してください。
監視するカウンター：使用可能なメモリ、合計サーバーメモリ、ターゲットサーバーメモリ、ページ/秒、バッファキャッシュヒット率
I/Oボトルネック
TempDBなどの通常のデータベース操作をサポートするのに十分なストレージが利用できない場合、I/Oボトルネックが発生する可能性があります。長い応答時間、アプリケーションの速度低下、頻繁なタスクのタイムアウトはすべて、I/Oのボトルネックがあることを示す重要な指標です。
アラームとしきい値アラートを使用して監視を設定し、どのアクティビティが過剰な量のストレージを使用しているかを特定することで、このタイプのボトルネックを回避できます。 I / Oボトルネックが発生した場合は、ディスクとの間のデータベースページの読み取りと書き込みを制限してください。これには、頻繁なインデックススキャン、非効率的なクエリ、古い統計をチェックして修正する必要があります。
監視するカウンター：平均ディスクキュー長、平均ディスク秒/読み取り、平均ディスク秒/書き込み、％ディスク時間、平均ディスク読み取り/秒、平均ディスク書き込み/秒
CPUのボトルネック
CPUのボトルネックの主な原因は、不十分なハードウェアリソースです。ログをチェックしてSQLServerが過剰なCPUを使用していないかどうかを判断することで、このボトルネックを特定するのはかなり簡単です。
理想的な世界では、専用のSQL Server専用サーバーを用意し、他のすべてのソフトウェアを別のマシンで実行することで、CPUのボトルネックを回避できます。これはほとんどのDBAのオプションではないため、CPUのボトルネックを解除する方法を知っておく必要があります。
最初のステップは、CPUの占有を特定することです。問題がどこにあるかがわかれば、クエリを調整したり、実行計画を改善したり、システムを再構成したりできます。
監視するカウンター：％プロセッサー時間、バッチ要求/秒、SQLコンパイル/秒、SQL再コンパイル/秒
SQLServerのパフォーマンスのボトルネックに関するストーリー
「SQLServerのパフォーマンスのボトルネックに対処する必要があります」と、ある金曜日の終わりに上司が言いました。
"どうして知っていますか？"聞いた。
「最近、データベースの速度が低下していると売り上げが不満を漏らしています。何が起こっているのかを確認する必要があります。」
"わかった。会議室を予約して、座って作業できるようにします。」
「気にしないでください」と上司は言いました。 「金曜日の午後遅くです。つまり、ボトルネックを研究するための最良の方法は、私たち自身のカップルを使用することです。市場のパイクパブに行きます。」
パイクプレイスマーケットにひっそりと佇むバーに足を踏み入れたところ、窓際に小さなテーブルがありました。
「好きなボトルネックは何ですか？」上司が尋ねました。
私は22オンスのボトルネックでいたずらなネリーに部分的だと言いました。
「良い選択だ」と上司は言った。 「あなたはそれを注文します、そして私はシトラスサマーエールを持っています。」
ボトルネックが発生するのを待っている間に、SQLServerのパフォーマンスのボトルネックに取り掛かりました。
「いくつかの場所で問題をチェックする必要があります」と上司は言いました。 「メモリ、ストレージ、またはプロセッサに問題がある可能性がありますが、ユーザーにはすべて同じように見えますよね？不器用なパフォーマンス。
「CPUの問題を見つけるのはそれほど難しくありません。それが問題である場合は、SQL Serverがプロセッサを占有し、プロセッサを常に急上昇させていることがわかります。
「メモリの問題の場合、アプリケーションがディスクを使い果たし続ける必要があるため、クエリの実行時間が長くなり、I/Oが増えるなどの問題が発生します。アプリケーションログでメモリ不足のメッセージを確認することもできます。
「そして、ボトルネックがストレージにある場合、ディスク上で極端なアクティビティが発生し、I/Oあたりの待機時間が長くなります。」
ボトルネックが発生しました。パフォーマンスの問題をより深く検討するため、慎重に調査しました。
SQLServerパフォーマンスのボトルネックの多くの潜在的な原因
「I/Oの問題だとしたら？」私は尋ねた。 「合計待機時間と比較して、WRITELOG待機時間が長すぎるかどうかを確認する必要があります。または、I / Oについて言えば、SQL自体に問題がある可能性があります。巨大なテーブルのNESTEDLOOPJOINのように非効率的なコードがある場合、SQLは内部テーブルの行を何十億回も読み取るように要求する可能性があります。それは本当にパフォーマンスを損なうでしょう。」
「そうかもしれない」と上司は言った。 「特にtempdbデータベースが適切に構成されていない場合、複雑な結合と並べ替えの操作は困難になる可能性があります。 Tempdbの競合は通常のデータベースロックのように見えますが、同時プロセスがすべて割り当てページで順番を待っているため、実際には競合がラッチされています。」
「これらすべてを調べるために使用できるツールはどれですか？」聞いた。
「SQLServerにはストアドプロシージャを調べるためのプロファイラーがありましたが、廃止されました。そのようなものは、それが最初のステップにすぎない場合でも、問題のあるクエリを見つけて診断するための良い方法です。次に、サーバーとデータベースの状態を監視し、問題を実行し、SQLを調整するのに役立つ動的な管理ビューと機能があります。」
「しかし、SQLServerには非常に多くの可動部分があります」と私は言いました。 「私はむしろ、全体像を外側から内側から見るツールが欲しいのです。」
「私もそうです。できればクラウドから、それを行うためにオンプレミスにハードウェアやソフトウェアを追加する必要はありません。」
SQLServerのパフォーマンスのボトルネックを解消する
パイクは混雑し始めていました。そして、上司と私がパブに座って話をするのと同じくらい喜んで、結局のところ、それは金曜日の夜でした。他にも行く場所、見る人、話すことなどがありました。
「ボトルネックを見つけたらどうすればよいですか？」聞いた。
「私たちはいつもの容疑者を切り上げます」と上司は言いました。 「メモリを使いすぎないようにするには、データベース開発者に、どのコードとクエリでメモリリークが発生しているかを通知する必要があります。 4つ、5つ、または6つのテーブルを結合する操作が見つかった場合は、データベースを再設計するためのSQLServerのチューニングのヒントとベストプラクティスを開発者に提供する必要があります。または、インデックスが多すぎて、それらを更新するサイクルを無駄にしている可能性があります。これは、インデックスが少なすぎるのと同じくらいCPUとI/Oにとって困難です。 SQL Serverのインデックスの断片化に問題があるか、廃止され重複しているインデックスを削除する必要があるかもしれません。」
「理にかなっている」と私は言った。 「たぶん、もっと多くのハードウェアを投入する必要があります。より高速なディスクは、I/Oのボトルネックに役立ちます。より多くのより高速なCPUは、クエリの応答時間に違いをもたらします。また、RAMを追加すると、SQLServerのスケーラビリティが向上します。」
「ええ」と上司は言いました。「しかし、最初に、根本的な原因が開発やDevOpsの問題ではないことを確認したいと思います。そうではないと確信したら、BuyMoreHardwareカードをプレイします。」
私たちはしばらく座って、パブが金曜日の夜の歓喜者でいっぱいになるのを見ました。
「上司」と私は尋ねました。「これらすべての人々は、ブロックされたセッション、最大I / O待機、ページの平均余命、およびバッファキャッシュのヒット率に対処する負担なしに、彼らがどれほど気楽な存在を導くかを知っていると思いますか？」 P>
「耐えるのは十字架ですよね？」上司が答えた。 「ほとんどの人は、私たちが何を経験しているのかわかりません。 SQL Serverのパフォーマンスのボトルネックに非常に静かに対処し、プレッシャーの下で非常に優雅に、そして非常に良い味で対処するのは良いことです。美味しさといえば、ボトルネックはどうですか？」
私がチェックしました。 「私のボトルネックは空です。私のボトルもそうです。」
"あまりにも私のもの。行く時間。やるべきことがあります。」
SQL Serverのボトルネックがゼロのシステムは可能ですか？
これらの3つの一般的なタイプのSQLServerのボトルネックを回避するために実行できる手順があることはわかっています。しかし、ボトルネックがゼロになるようにSQL Serverデータベースを適切に構成することは可能ですか？
簡単な答えはおそらくそうではありません。最も勤勉なDBAでさえ、SQLServerのボトルネックがときどき発生します。ただし、ボトルネックを積極的に回避し、パフォーマンスへの影響を最小限に抑えるための措置を講じることができます。たとえば、Brent Ozarは、Perfmonカウンターを監視してSQL Serverを調整するための優れたヒントをいくつか提供しています。また、sys.dm_os_performance_countersビューを使用して、ボトルネックを特定し、迅速に修正することができます。
SQL Serverのボトルネックは、DBAの現実です。幸い、適切な監視、入念な監視、頻繁なクエリチューニングにより、ユーザーが問題があることに気付く前に、パフォーマンスの問題に対処できます。