web-dev-qa-db-ja.com

AWS RDSは、DB接続数が少ないにもかかわらず、書き込み操作数/秒が大幅に増加していますか？

MYSQL 5.5を実行しているマルチAZ AWS RDSインスタンスがあります

DB接続が低い（場合によってはゼロ）にもかかわらず、書き込み操作数/秒がかなり急速に増加していることに気づきました-過去12か月間および過去2週間の平均書き込み操作数/秒、および過去2週間の平均DB接続数のグラフを参照してください：

write ops last 12 monthswrite ops last 2 weeksdb connections last 2 weeks

スキーム全体で書き込み操作/秒の全体的なレベルが低いことはわかっていますが、今後数か月でより多くの量（100倍など）が予想され、問題を確実に解決したいと考えています。

これらの書き込み操作の原因を理解しようとしています。 RDSインスタンスに接続して実行してみました：

show full process list

そしてこれは示しています：

+--------+----------+---------------------------------------------------+-------+---------+------+-------+------------------+
| Id     | User     | Host                                              | db    | Command | Time | State | Info             |
+--------+----------+---------------------------------------------------+-------+---------+------+-------+------------------+
|      7 | rdsadmin | localhost:51067                                   | mysql | Sleep   |    9 |       | NULL             |
| 705938 | rdsuser  | ip-xx-xx-xx-xx.eu-west-1.compute.internal:xxxx | NULL  | Query   |    0 | NULL  | show processlist |
+--------+----------+---------------------------------------------------+-------+---------+------+-------+------------------+

つまり、アクティブなスレッドはありません。

何が起こっているかについての考えを感謝します。

[〜＃〜] update [〜＃〜]ローランドの返答のおかげで、さらに掘り下げました。特に、RDSインスタンスに一般的なログ記録と低速のクエリログ記録を追加し、毎分実行していたcronジョブが不必要なクエリを実行しているため、インスタンスが不要な作業を大量に実行していることがわかりました。

RDS管理コンソールで新しいパラメーターグループを作成し、次のように設定することで、ロギングをオンにしました。

general_log = 1
slow_query_log = 1
long_query_time = 1

私も使用したことに注意してください

CALL mysql.rds_rotate_slow_log;

そして

CALL mysql.rds_rotate_general_log;

ログファイルをローテーションするために-それらはかなり速くかなり大きくなるので。

mysqlinnodbamazon-rds
5
CharlesA

これらのプロセスがMySQLインスタンスの唯一のDB接続である場合、書き込みI/Oの2つのソースのみを調べることができます。

VM MySQLを収容する

Amazon MySQL RDSを使用しているため、プロビジョニングされたVM内のMySQLインスタンスにのみアクセスできます。内部的な目的のためだけに、MySQLから多くの読み取りが行われる可能性があります。プロセスID 7はrdsadminであることに注意してください。 MySQLの使用状況の統計をディスクにロールアップして、統計を提示するために提供するRDS APIにレポートを返すことができます。

Amazon EC2インスタンスのMySQLにデータを移動することで、それを排除できると思います。もちろん、自分の統計情報を管理する必要があります。

InnoDBアーキテクチャ

InnoDB Architecture

InnoDBには、書き込みを必要とする多くの可動部分があります。

  • バッファプール
    • 変更された（ダーティ）InnoDBテーブルのデータおよびインデックスページは、システムテーブルスペース（別名ibdata1）内の二重書き込みバッファーに体系的に書き込む必要があります
    • セカンダリインデックスへの変更である挿入バッファは、システムテーブルスペース内の挿入バッファに体系的に書き込む必要があります
  • ログバッファ：いっぱいになると、ログバッファ内の変更をREDOログ（別名ib_logfile0、ib_logfile1）に書き込む必要があります。高書き込みシステムでは、REDOログへの書き込みを減らすために、 innodb_log_buffer_size を256Mに増やす必要があります。
  • ロールバックセグメント/元に戻すスペース：システムテーブルスペース内には1023個のロールバックセグメントがあります。 INSERT、UPDATE、DELETEを実行するたびに、1つのトランザクションは単一のロールバックセグメントを使用して、トランザクションが変更しようとしているデータの以前の状態を保存します。 UNDOスペースのクリーンアップ専用の内部スレッドがあります。したがって、大量の大量の書き込み（または少しの書き込みでも）には、UNDOスペースのクリーンアップを行う内部スレッドからのディスクI/Oが必要になります。

私は以前にこれについて書いた

3
RolandoMySQLDBA