RDS (MySQL) で大規模テーブルを運用する際の注意点 | Hack

この投稿は AWS Advent Calendar 2014 の 22日目の記事です。 RDS で MySQL を運用中に、想定外の CPU スパイクに悩まされたことがありましたので纏めておきます。 まずは、CloudWatch のグラフを見てみましょう。 所々で CPU スパイクが発生しているのがわかるかと思います。一見すると法則性がないようにも見えます。一般的には CPU リソースを消費する要因としては、アクセス過多やバッチ処理などで負荷をかけたケースが殆どです。しかし、今回のケースはユーザー側では何も負荷をかけておらず、RDS へのアクセスがゼロのサーバーでも同様の CPU スパイクが発生することがわかりました。 CPU スパイクの原因は？ では、CPU スパイクの原因は何だったのでしょう？その後の調査で「RDS の定期メンテナンスジョブ」が原因であることがわかりました。 以下、メン

[toaruR]

おのれibdata1……

[msykt]

なんと…/“MySQL の総テーブル数に比例して負荷は大きくなる。”

[Hayato]

腹を括るための1情報として。

[rch850]

めまいがする＞“万単位のテーブル数”

[yass]

" CPU スパイクの原因は何だったのでしょう？その後の調査で「RDS の定期メンテナンスジョブ」が原因であることがわかりました。"

[kasumani]

RDS (MySQL) で大規模テーブルを運用する際の注意点 この投稿は AWS Advent Calendar 2014 の 22日目の記事です。 RDS で MySQL を運用中に、想定外の CPU スパイクに悩まされたことがありましたので纏めておきます。 まずは、CloudWatch の