web-dev-qa-db-ja.com

クエリの結果をRDSから10,000回フェッチするのにかかる時間が非常に不均一なのはなぜですか？ （実験）

tl; dr：EC2から要求されたときにRDSからSELECTステートメントの結果を10,000回フェッチするのにかかる時間が非常に不均一なのはなぜですか？

中小規模のRDSサーバーの結果で質問を更新しました

SQLクエリの結果をフェッチするのにかかる時間をチェックするためにAWSを実験していると、次の非常に不均一な結果が得られました。

私はPHPコードを記述して、SELECTクエリの要求をn回フェッチするのにかかった時間を報告しました。サーバー。

while($flag<n)
    {
       $t=microtime(true);
       $result=$con->query($q);
       $t=microtime(true)-$t;
       $total+=$t;
       $flag++;
    }

環境：

  • すべてのトランザクションは、AWSのプライベートvpc内で実行されました
  • すべてのサーバーは異なるゾーンにあります
  • 各サーバーでのMySQLの設定は次のとおりです。EC2でのMySQL：バージョン= 5.6、RDSで：5.5、query_cache_size = 16777206、query_cache_state = ON。
  • データベースA大規模データベース〜= 5GB、クエリされたテーブルには〜= 20000行がありました。

サーバー：

  • EC2 A、アベイラビリティーゾーン：us-east-1e、タイプ：t2.micro。
  • EC2 B、アベイラビリティーゾーン：us-east-1b、タイプ：t2.micro。
  • RDSアベイラビリティーゾーン：us-east-1c、タイプ：db.t2.micro、db.t2.small（更新済み）、db.t2.medium（更新済み）

結果 ：

SELECTクエリの実行に10,000ループかかる時間：

  • 要求サーバーB、データベースサーバーB

5回の試行の結果は次のとおりです：20、21、20、20、21（すべて秒単位）

  • 要求サーバーA、データベースサーバーB

5回の試行の結果は次のとおりです：33、33、33、33、3（すべて秒単位）

  • 要求サーバーA、データベースサーバーRDS（マイクロ）

11回の試行の結果は次のとおりです。272、709、49、48、711、593、47、316、153、47、636（すべて秒単位）

  • 要求サーバーA、データベースサーバーRDS（小）

5回の試行の結果は次のとおりです。53、54、53、158、698（すべて秒単位）

  • 要求サーバーA、データベースサーバーRDS（中）

5回の試行の結果は次のとおりです。96、123、579、252（すべて秒単位）

SELECTステートメントの10,000ループのテストでRDSにかかる時間が非常に不均一なのはなぜですか？また、EC2サーバーよりも長いのはなぜですか？

[ネットワークが原因ではないと思います。より少ないループ（1000ループ）で実験を行ったとき、EC2-> RDSの読み取り値は4、5、5、5、4でした。 。]

各フェッチ要求の時間を記録すると、次のことに気付きました。

  • RDSで10,000ループに153秒かかった場合：

各クエリにかかった平均時間：0.015419

クエリの数が10000：1644から平均時間を超えました

完了までに平均時間を超えたクエリにかかった合計時間：119.364（合計時間の78％）

  • RDSで10,000ループに636秒かかった場合：

各クエリにかかった平均時間：0.063605

クエリの数が10000：8629から平均時間を超えました

完了までに平均時間を超えたクエリにかかった合計時間：628.6426（合計時間の98.8％）

Edit1：

10,000 reqのサイクルで各フェッチ要求の時間を記録しました。いくつかの要求の後、各reqの時間が〜0.07（〜0.003）秒に増加することに気付きました。ただし、この増加は、ランダムな数の要求の後に発生します。同様に、場合によっては〜8000リクエストの後、場合によっては〜3000リクエストの後。理由は何でしょうか？また、10,000リクエストに約45秒かかる場合、RDSのCPU使用率は約5％です。 100秒を超えると、CPUは約10〜15％になります。

Edit2：

RDSサーバーをt2.microからt2.smallにアップグレードし、さらにt2.mediumにアップグレードしました。ここでも、パフォーマンスは不均一でした。

  • 要求サーバーA、データベースサーバーRDS（小）

5回の試行の結果は次のとおりです：53、54、53、158、698（すべて秒単位）

  • 要求サーバーA、データベースサーバーRDS（中）

5回の試行の結果は次のとおりです：96、123、579、252（すべて秒単位）

Edit3：

RDSを別のゾーンに切り替えました。現在、測定値は一貫しているようです。問題は、ノイズの多い隣人によるCPUの盗難であった可能性があります。

  • 要求サーバーA、データベースサーバーRDS（小さい、別のゾーンにある）

5回の試行の結果は次のとおりです：156、151、151、151、151、302（すべて秒単位）

mysqlamazon-ec2amazon-web-serviceslatencyamazon-rds
4
Sumit Sinha

db.microインスタンスを使用していることに気づきました。 EC2と同様に、マイクロインスタンスは予算にやさしいように設計されていますが、パフォーマンスが犠牲になります。とは言うものの、CPU時間がインスタンスに与えられるため、通常のインスタンスと比較して、これらのタイプのサーバーをロードすると、はるかにパフォーマンスが低下します。 「同じハードウェアを共有する他のインスタンスと比較して。

ポイントを証明するために、db.mediumインスタンスに対してテストを再実行すると、一貫性が大幅に向上します。

6
Nathan C