データベースの負荷テストと容量計画はどのように行いますか?


34

これは、データベースの容量計画に関する標準的な質問です。

関連:

データベースのキャパシティプランニングのツールと方法に関する標準的な質問を作成したいと考えています。これは標準的な質問であることを意図しています。

明らかに、一般的なワークフローは次のとおりです。

  • シナリオを準備する
  • 監視を追加
  • トラフィックを追加
  • 結果を評価する
  • 結果に基づいて修正する
  • すすぎ、適度に幸せになるまで繰り返します

さまざまなWebサーバー、フレームワークなどのさまざまなツールとテクニック、およびベストプラクティスについてお気軽にご説明ください。


データベースは、スタンドアロンシステムではありません。多くの場合、その前にある大きなアプリケーションサーバーの主要なコンテキストで見られます。DBはバックエンドデータデバイスです。したがって、負荷をテストするときは、それを考慮する必要があります。
ニルス

回答:


24

ディスクとRAMの容量計画

データベースサーバーのディスク容量とメモリ容量を計画するのは困難です。多いほど良い。速いほど良い。

一般的なガイドラインとして、以下を提供します。

  • あなたはよよりもあなたは多くのディスク領域が必要EVER必要です。
    今後3〜5年間に必要なディスク容量を最もよく見積もってから、2倍にします。
  • データベースインデックスをメモリに保持し、最大のクエリを少なくとも2回以上処理し、OSディスクキャッシュを正常に保持するための十分な空き領域を確保するのに十分なRAMが必要です。
    インデックスサイズはデータベースに依存し、他のすべてはデータセットとクエリ/データベース構造に大きく依存します。「最大のテーブルの少なくとも2倍のサイズ」を提案として提供しますが、この提案は、最大のテーブルが数十または数百ギガバイトになる可能性がある非常に大規模なデータウェアハウジング操作に分類されることに注意してください。

すべてのデータベースベンダーには、ディスク/メモリ/ OSカーネルのパフォーマンスチューニングに関するいくつかの指示があります。展開前に、このドキュメントを使用してください。それが役立ちます。


ワークロードのベンチマークと容量計画

まだデプロイしていないと仮定して…

多くのデータベースシステムにはベンチマークツールが付属しています。たとえば、PostgreSQLにpgBenchが付属しています。
これらのツールは、データベースのパフォーマンスをベンチマークする最初の目的地です。可能であれば、すべての新しいデータベースサーバーでそれらを実行して、データベースサーバーが実行できる "作業量"を把握する必要があります。

ベンチマークABSOLUTELY MEANINGLESSに対するより現実的なアプローチを検討する生のベンチマークを用意しました。データベーススキーマをロードし、ダミーデータを入力するプログラムを作成してから、そのデータに対してアプリケーションのクエリを実行します。
このベンチマークでは、3つの重要な要素をベンチマークします。1.データベースサーバー(ハードウェア)2.データベースサーバー(ソフトウェア)3.データベース設計、および上記(1)および(2)との相互作用。

これには、次のような単純な事前作成されたベンチマークよりも多くの労力が必要であることに注意してください。データを取り込むpgBenchにはコードを書く必要があります。
また、この種のテストはかなり正確です。スキーマとクエリを使用しているため、それらがどのように実行されるかを確認でき、データベース/クエリをプロファイリングおよび改善する機会を提供します。

これらのベンチマークの結果は、データベースの理想的なビューです。安全のために、実稼働環境でこのパフォーマンスの50〜70%のみを達成すると想定します(残りは、予期しない成長、ハードウェア障害、ワークロードの変更などを処理できるクッションです)。


遅すぎる!生産中です!

システムが実稼働状態になったら、「ベンチマーク」には本当に遅すぎます-クエリのログ/タイミングを短時間オンにして、実行にかかる時間を確認し、オフ中に大きなデータセットに対して「ストレステスト」クエリを実行できます時間。また、システムのCPU、RAM、およびI / O(ディスク帯域幅)の使用率を調べて、負荷がどの程度かを把握することもできます。
残念なことに、これらのことはすべて、システムが何をしているのか、飽和にどれだけ近いかという漠然とした概念を提供することです。
それは…


継続的な監視

システムに突然新しい/異なる使用パターンが見られる場合、世界のすべてのベンチマークは役に立ちません。
良くも悪くもデータベースの展開は静的ではありません:開発者は物事を変え、データセットは成長し(縮小しないように見えます)、ユーザーはテストで予測しなかったイベントの異常な組み合わせを何らかの形で作成します。

データベースの適切なキャパシティプランニングを行うために、何らかのパフォーマンスモニタリングを実装して、データベースのパフォーマンスが期待を満たしていないことを警告する必要があります。その時点で、修復アクション(新しいハードウェア、DBスキーマ、またはリソースの使用を最適化するためのクエリの変更など)を検討できます。


注:これは、データベースハードウェアのサイズを決定し、それがどれだけの悪用を行うかを把握するための非常に高度で一般的なガイドです。特定のシステムがニーズを満たしているかどうかを判断する方法がまだわからない場合は、データベースの専門家に相談してください。
また、データベース管理専用のStack Exchangeサイトdba.stackexchange.comもあります。質問のアーカイブを検索するか、データベースエンジンに固有のタグを参照して、パフォーマンスチューニングに関する詳細なアドバイスを確認してください。


1
それに加えて、今日では、スワップ/オンディスク操作にSSDを使用できます。これにより、ディスク上の大きな一時テーブルを使用するクエリが高速化されます。したがって、一般にSSDを追加することは非常に良い考えです。
ピーター

2
@PeterスワップスペースにSSDをお勧めしません(アクティブにスワップしている場合は、非常に高い解約率があります)。一時テーブルスペースにSSDが使用されており、良い結果が得られています。
voretaq7

1
SSDについてのコメントにあるこのアドバイスは7年前のものです。データベースサーバー上のデータベースを保持するすべてのストレージは、2019以降ではSSDである必要があります。
マークヘンダーソン

1

一般に、パフォーマンスをテストするには現実的なユースケースが必要です。ベストプラクティスは、アプリケーション開発者とエンドユーザーを巻き込むことです。

通常、彼らがしていることを記録し、ユースケースごとにそれをパラメータ化します(コンテンツ、同時アクションの数)。

次に、クライアント側を構築します。多くの場合、1台の物理マシンでは本番環境の負荷を十分に満たせません。

その後、それを起動し、計算し、強化し、再度テストします。

ボトルネックが発生する場所には驚くでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.