0

運用環境を自己ホスト型ソリューションから Amazon aws に移行することを考えています。さまざまなサービスを調べて、mysql インスタンスの代わりにRDSを使用することを考えました。マスターに使用しているハードウェアは、rds (Quadruple Extra Large DB Instance) を使用するときに入手できる最高のハードウェアよりも優れているようです。本番環境を aws に単純に移動して、パフォーマンスがまだ十分であるかどうかを確認することはできないため、事前にいくつかのテストを行いたいと思います。

現在のマスターから完全なクエリ ログを作成し、rds インスタンスを構成して、それに対して完全なクエリ ログの再生を開始することを考えました。実際、この種のテストが良いアイデアかどうかはわかりませんが、rds に移行するときに mysql のパフォーマンスが劇的に低下しないことを確認するためのより良い方法があるかどうか教えてくれると思います。

  1. 完全なクエリ ログを再生するための優先ツールはありますか?
  2. テストの実行中にどのメトリックを確認する必要がありますか
    • CPU使用率?
    • メモリ使用量?
    • ディスクの使用状況?
    • クエリ時間?
    • 他に何か?

前もって感謝します

4

1 に答える 1

0

クエリ ログを再生しないことをお勧めします。ほとんどの場合、必要な情報が得られず、かなりの労力がかかります。

まず、データの挿入、更新、または削除の際にクエリ ログを再生しても制約が破られないように、また後続の「選択」クエリで必要なレコードが検出されるように、データベースを準備する必要があります。これは、おもちゃのデータベース以外では明らかに些細なことではありません。バックアップを取ってログを再生するだけでは、DML ステートメントの順序が本番環境で発生したものと一致するとは限りません。これは間違った安心感を与えてしまうかもしれません。探しているデータが存在しないため、すべての select ステートメントが数ミリ秒で返されます!

第二に、負荷とパフォーマンスのテストは、本番環境で発生したことを再現することによってほとんど機能しません。これは、(通常) システムを停止させるピーク条件を反映していません。たとえば、ほとんどの本番システムは、ほとんどの場合 50% 未満の容量で正常に動作しますが、日中はスパイクが発生し、容量の 80% 以上に達する可能性があります。これは、新しい環境がピークを処理できるかどうかに注意してください。 .

JMeterのようなツールを使用してパフォーマンス スクリプトを作成することをお勧めします (JDBC ドライバーを使用してデータベースに直接、または Web アプリケーションを使用している場合はフロント エンドを介して)。パフォーマンス スクリプトは、ユーザーから見た動作を反映し、パラメータ化して、レコードが作成される順序に依存しないようにする必要があります。

いくつかのパフォーマンス目標を設定し (理想的には、現在の生産レベルに基づいて、スパイクをカバーするための乗数を使用します)、たとえば「100 人の同時ユーザー、1 秒以上かかるクエリはありません」)、JMeter を使用してその負荷をシミュレートします。初めて到達した場合は、おめでとうございます - 家に帰りましょう! そうでない場合は、パフォーマンス カウンターを見て、ボトルネックがどこにあるかを確認します。そのボトルネックを軽減できるかどうかを確認してください (またはクエリを調整すると、優れたオンプレミス ハードウェアがパフォーマンスの問題を隠している可能性があります)。一般的なボトルネックは、CPU、RAM、およびディスク I/O です。

さまざまなテスト シナリオ (「多数の書き込み」、「多数の読み取り」、「多数のレポート クエリ」) を試して、それらを混ぜ合わせます。

アイデアは、システムのボトルネックを理解し、それらのボトルネックからどれだけ離れているかを確認し、それらを軽減するために何ができるかを理解することです. それがわかれば、移行の決定ははるかに確実になります。

于 2012-09-26T08:48:29.110 に答える