performance - I / Oプレッシャーを減らすためにクエリを最適化することは理にかなっていますか？

Question

独自のSQLServer2008に対応する読み取り専用データベース（製品）があります。

私はすでにアクティビティモニターで最も高価なクエリを見てクエリを最適化しました-レポート。CPUコストでレポートを注文しました。今では50クエリ/秒のようなものがあり、300ミリ秒を超えるクエリはありません。

CPU時間は問題なく（30％）、メモリは20％しか使用されていません（64GBのうち）。

1つの問題があります。ディスク時間は100％安定しています（アイドル時間のパフォーマンスカウンターを調べ、ideras SQL診断マネージャーを使用しました）。product dbは、別のマシンにあり、テーブルが小さい注文dbとは異なる動作をすることがわかります。プロファイラートレースを見ると、列「read」に50.000より大きい値を示すクエリがproduct-dbにあります。 。私の注文DBでは、これらの値が1000を超えることはありません。product-dbのクエリは、多くの共通テーブル式を使用し、大きなテーブルで機能します（一部は約500万エントリです）。

I / Oパフォーマンスのためにクエリを最適化するために時間を費やす必要があるのか​​、それともサーバーを追加するだけなのか、私にはわかりません。クエリ期間を最適化することで、不足しているインデックスをすでに追加しました。i / oの最適化は通常行われていることですか？

Answer 1

要するに、はい。CPUとIOの両方を最適化します。

CPUが高いクエリは、不要なメモリ内ソート、（場合によっては非効率的な）ハッシュ結合、または複雑なロジックを実行する傾向があります。

IO（ページ読み取り）が高いクエリは、全表スキャンを実行したり、他の非効率的な方法で動作したりする傾向があります。

10回のうち9回、同じクエリがリストの一番上に表示されますが、高CPUで作業したことがあり、それでもパフォーマンスに不満がある場合は、必ず次に高IOプロシージャで作業してください。

Answer 2

次のボトルネックは常にあります。

彼らが言うには。

CPU使用率を調整したので、I/O負荷が支配的になるのは当然のことです。あなたのパフォーマンスはすでに受け入れられていますか？はいの場合は停止し、いいえの場合はさらに調整に何時間投資する必要があるかを見積もる必要があり、別のサーバーまたはより多くのハードディスクを購入する方が安い場合があります。

再度I/Oチューニングについては、簡単な対策で何ができるか試してみてください。CPUをI/Oと交換したり、その逆を行ったりできる場合があります。圧縮はその一例です。次に、現在のボトムネックであるコンポーネントを調整します。

I / Oを高速化する前に、生成されるI/Oを減らしてみてください。

Answer 3

クエリのIOパフォーマンスが明らかに向上していることを確認しますが、さらに重要なことは、サーバーレベルでIOパフォーマンスを向上させる方法を確認することです。

他のリソース（CPUとメモリ）が過負荷になっていない場合は、おそらく新しいサーバーは必要ありません。ログと一時ファイル用にSSDを追加することを検討するか、DB全体をSSDのアレイに手頃な価格で収めることができるかどうかを検討してください。

もちろん、ディスクIOのボトルネックを解消すると、CPU使用率が上がる可能性がありますが、パフォーマンスが許容範囲に近い場合は、今のところ最適化を停止できる程度まで改善される可能性があります。

Answer 4

SSDまたはDBに最適化されたSANを使用していない限り、データベースアプリケーションではほとんどの場合IOが制限になります。

そうです、可能な限りそれを取り除くために最適化してください。

テーブルインデックスは最初に行うことです。

次に、DBファイルの完全なサイズまで、可能な限り多くのRAMを追加します。

次に、データテーブルをパーティション分割して（それが合理的な方法である場合）、必要なテーブルまたはインデックスのスキャンが1つまたは2つのテーブルパーティションでのみ実行されるようにします。

次に、RAMをさらに搭載した大型のマシンを購入するか、SSDまたはSSDを搭載したSANまたはSANを購入すると思います。

または、データベースアプリケーション全体を再構築して、NoSQLやデータベースシャーディングなどを使用し、すべてのリレーション、結合、制約などを中間インターフェイスレイヤーに実装します。