AWSにMySQL m2.2xlargeインスタンスがあります。 MySQLデータディレクトリはルートEBS /にあります。それはRAIDではない単一のEBSです。私たちは3つのメインテーブルを持っています。それらのうちの1つTable Cは、コンテンツの中で最大のもので、最後の日分のデータのみが使用されます。これらのテーブルの挿入率は、1日あたり80.000行です。 3つのテーブルには約4200万行があります。 innodb_buffer_pool_sizeには〜30GBのインスタンスRAMがあります。EC2/EBSのMySQL。遅すぎる？
Table A最も重要なのは、そのデータ長が〜33ギガバイトとインデックスが11ギガバイト Table Bは、データ長を有し~~ 8ギガバイトおよび当社のウェブサイトにインデックス〜5ギガバイト
、二つの主要なクエリ（レイテンシワイズ）がされているありますこのように：ほとんどのページで
SELECT * FROM TableA WHERE id in (.....)
SELECT * FROM TableB JOIN .... WHERE id in (.....)
（...）これらのクエリは< 50ミリ秒ごとに服用して、いくつかの〜50件の最近のIDになります。しかし、他のいくつかのページでは古いIDを使用していましたが、これらのクエリの待ち時間は500ミリ秒、800ミリ秒、最長1.5秒に急増しました。
私はMysqlを再起動した後、キャッシュ/メモリにインデックスを強制的に入れるためにSELECT id FROM TableBを実行しました。 Table Bクエリはまだ遅くなります。それから私はSELECT * FROM TableBをやった。そして、キャッシュ/メモリ内のテーブル全体が本当に速くなりました（< 50ms）。
私の質問：> 500ms、> 1000msはPRIMARY KEYで行を取得するだけの妥当な遅延ですか？ 42Mのテーブルでも？すべての行がディスクに入っていても？それは私のためにあまりにも多くのようです。
MySQLデータを一時記憶域（/ mnt）に移動するとこれが改善されますか？プロビジョニングされたIOPSを使用すると役立つでしょうか？
あなたは、単一のEBSボリュームまたはRAIDを使用していますセット？/mntを使うと、しっかりした複製がなければやや危険です。プロビジョニングされたIOPSは、あまりコストをかけずにテストできます。 – datasage
シングルEBS。新しいEBSボリュームにデータセット全体をダンプすることなく、プロビジョニングされたIOPSに移行することはできません。だから私は最初にいくつかの知識が、移動の仕事の価値がある場合はしたいと思います。 –
私はあなたのボリュームをスナップすることができ、IOをプロビジョニングしたスナップショットから新しいボリュームを作成できると思います。次に、それを新しいインスタンスに接続してテストします。 ec2の素晴らしい点は、新しいインスタンスをプロビジョニングして、パフォーマンス変更をコミットすることなくテストする柔軟性です。 – datasage