ここ数日、IOPS の上限に達していました。IOPS を数回追加しました。1250 -> 2500 -> 4500。各ステップで、読み取りと書き込みの間で最大限に達するため、利用可能な IOPS をすべて使用していることがすぐにわかりました。
ついに今朝、別の大規模な顧客が参加し、CPU、メモリ、IOPS が限界に達しました。システムを継続して稼働させるために、より大きなデータベース タイプを提供することにしました。db.m5.xlarge から db.m5.2xlarge に変更しました。また、アップグレードにより IOP が 8000 に上がりました。
現在、CPU は比較すると打撃を受けており、IOPS は実質的に 0 です。アプリは応答しているように見えますが、タスク キューは非常に遅いです。
コードは変更されておらず、データベースのみが変更されています。何が足りないのでしょうか? RDS が正しくレポートしていないのでしょうか?
過去 3 日間の読み取り IOPS の急上昇がわかるでしょう。これは、より高い IOPS プロビジョニングと相関しています。
答え1
おそらく、クエリが急降下したのでしょう。(わかりやすい説明をありがとうございます。考えられる説明は次のとおりです。)
例: クエリが 7000 万行の 7 GB テーブル (有効なインデックスなどなし) をスキャンしているとします。
ケース 1: RAM = 8GB; innodb_buffer_pool_size= 6GB。クエリは、スキャンを完了するためにすべてをキャッシュから追い出します。これには、安定した I/O が必要です。他のすべてのクエリも影響を受けます。それらのデータも RAM から追い出されたためです。
ケース 2: RAM = 16 GB; innodb_buffer_pool_size= 12 GB。最初のスキャンではテーブル全体がキャッシュにロードされ、そのクエリのその後の実行では I/O を実行する必要がありません。キャッシュの競合がないため、他のクエリもより高速に実行されます。
どちらの場合も、7000 万行すべてを調べるのに大量の CPU が消費される可能性があります。
プラン A: RAM、CPU、不要な IOP を増やすためにお金をかける。
プラン B: 非常に厄介なクエリを見つけて、最適化を手伝ってもらいます。その後、より安価な VM に戻ることができます。
クエリとSHOW CREATE TABLE関連するテーブルを指定してください。複合インデックスを追加するか、クエリを再作成するだけで解決できる場合があります。
答え2
ここで重要なのは、何もしないことです。「魔法のように」CPU は期待どおりに正常化しました。幸いなことに、クエリのいくつかの問題点、いくつかの過剰なロック、そして InnoDB/RDS/MySQL のチューニングに関する膨大な知識がわかりました。
おそらく、RDS はインデックスをゆっくりと最適化していたか、あるいは私が完全に理解していない何かを行っていたのでしょうが、今ではレイテンシは驚くほど向上し、スループットと使用率は、さらに 4 つのコアと 2 倍のメモリで期待どおりになっています。
