5

AWS に MySQL m2.2xlarge インスタンスがあります。MySQL データ ディレクトリは、ルート EBS / にあります。RAID ではなく単一の EBS です。3つのメインテーブルがあります。そのうちの 1 つはTable Cコンテンツが最大で、過去 1 日分のデータのみが使用されます。これらのテーブルの挿入レートは、1 日あたり約 80.000 行です。3 つのテーブルには、約 4,200 万行あります。innodb_buffer_pool_size には、約 30 GB のインスタンス RAM があります。

Table Aが最も重要で、そのデータ長は ~33GB でインデックスは ~11GB で、 Table Bデータ長は ~8GB でインデックスは ~5GB です。

私たちのウェブサイトでは、2 つの主要なクエリ (レイテンシに関して) は次のようになります。

SELECT * FROM TableA WHERE id in (.....)

SELECT * FROM TableB JOIN .... WHERE id in (.....)

ほとんどのページでは、(...) は最近の 50 個までの ID であり、これらのクエリはそれぞれ 50 ミリ秒未満かかります。しかし、他のいくつかのページでは古い ID にヒットし、これらのクエリのレイテンシは 500 ミリ秒、800 ミリ秒、最大 1.5 秒に急上昇しました。

Mysql の再起動後、SELECT id FROM TableBインデックスをキャッシュ/メモリに強制するテストを行いました。クエリはTable Bまだ遅くなります。それから私はしましたSELECT * FROM TableB。そして今、テーブル全体がキャッシュ/メモリ内にあるため、クエリは非常に高速になります (<50ms)。

私の質問: > 500 ミリ秒、> 1000 ミリ秒は、PRIMARY KEY によって行を取得するだけのクエリの妥当な待機時間ですか? 42M テーブルでも？すべての行がディスクにある場合でも? 私には多すぎるようです。

MySQL データを一時ストレージ (/mnt) に移動すると、これは改善されますか? プロビジョンド IOPS の使用は役に立ちますか?

4

2 に答える 2

8

免責事項: 私は (My)SQL パフォーマンスの専門家ではありません。ユース ケースの AWS の側面についてコメントしているだけです。

それが邪魔にならないように、まず第一に、対処すべきいくつかの質問があります。

MySQL データを一時ストレージ (/mnt) に移動すると、これは改善されますか?

EBS からエフェメラル ストレージにデータを移動すると、MySQL クエリのパフォーマンスが向上しますか?同じ質問に対する回答を提供しました。、いくつかの重要な詳細については、それを確認してください - TL;DR: 耐久性が必要な場合 (自分が何をしているのかを正確に知っている場合を除く)、および過去も、今日の観点からは明らかに間違っていないとしても、せいぜい疑わしいものです。

プロビジョンド IOPS の使用は役に立ちますか?

もちろん、プロビジョンド IOPS ボリュームは、ストレージ パフォーマンスとランダム アクセス I/O スループットの一貫性に敏感な I/O 集約型ワークロード、特にデータベース ワークロードのニーズを満たすように特別に設計されています。投稿Fast Forward - EBS のプロビジョンド IOPS を参照してください。一般的な導入のためのボリューム。

  • これらは、最適化された構成スタックを使用し、EBS I/O 用の追加の専用容量を提供するEBS 最適化インスタンスと連携するのが理想的です (必ずしもそうである必要はありません) 。この最適化は、EBS I/O と Amazon EC2 インスタンスからの他のトラフィックとの間の競合を最小限に抑えることで、EBS ボリュームに最高のパフォーマンスを提供します。

  • 具体的には、必要な I/O パフォーマンスを確認する方法と、用途に応じてRAID やプロビジョンド IOPSでこれらの要件を満たすために EBS パフォーマンスを向上させるためのオプションについて説明している専用のセクションEBS パフォーマンスの向上 をお読みください。場合。

私の質問: > 500 ミリ秒、> 1000 ミリ秒は、PRIMARY KEY によって行を取得するだけのクエリの妥当な待機時間ですか? 42M テーブルでも？すべての行がディスクにある場合でも? 私には多すぎるようです。

前述のように、値をそのように判断することはできませんが、仕様を考えると、m2.2xlarge インスタンスが 34.2 GiB のメモリを「のみ」備えており、innodb_buffer_pool_sizeすでに ~30GB を割り当てている限り、メモリ競合があるようです-これはOS および/または MySQL の他のメモリ要件を考えると、私には少し高くなります。そのため、すでにスワッピングが関係している可能性があり、これにより、発生しているキャッシュ/メモリ ウォーミング動作を完全に説明できます。

  • データベース ワークロードの一般的な推奨事項として、最近では、データセットが完全に RAM に収まるようにすることが、これまでで最大の費用対効果であるように思われます。場所）。

最後に、AWS EC2 での PostgreSQL パフォーマンスの向上に関する最近の投稿を読むことをお勧めします。そこでの推奨事項は主に AWS 側にも対処しており、それに応じて MySQL にも適用されます。セクション耐久性のあるデータベースは、上記の私の提案をほぼ要約しています。

データを気にする耐久性のあるデータベースの場合、高 I/O インスタンスの代わりに必要なのは、EBS ストレージ サーバーへのネットワーク帯域幅を保証するEBS 最適化インスタンスです。プロビジョニングされた IOPでEBS ボリュームを使用し、最良の結果を得るには、EBS ボリュームのグループを RAID10 アレイにストライプ化します。EBS パフォーマンスの向上を参照してください。

于 2013-02-13T19:01:34.467 に答える
0

EC2 インスタンスよりも SQL サブクエリを IN ステートメントに含めると、デフォルトで MySQL 5.5 が使用されるため、非常に遅くなる可能性があります (詳細については、MySQL を参照してください。 EC2 では非常に遅いです) 。

于 2013-06-22T21:12:21.707 に答える