Amazon RDS MySQLインスタンスで高いCPU使用率をデバッグするのに苦労しています

m1.xlarge MySQL RDSサーバーを実行しており、CPU使用率が高いという問題があります。数週間前に、大きなインスタンスでCPU使用率が100％に達するという問題がありました。サイズをxlargeにアップグレードすると、しばらくの間物事は安定しましたが、CPU使用率は徐々に再び上昇しました。

先週かそこらで、CPU使用率は90年代後半で、昨日は一貫して100％前後に達していました。これにより、本番サイトは停止しました。dbサーバーを再起動すると、数時間以内にCPU使用率が同じレベルに戻りました。

mysqlサーバーでshow processlistを実行し、MySQL adminを介して同じを監視しています。特に長時間実行されるクエリや大量のクエリも存在しないようです。長い間スリープ状態になっているプロセスがいくつかあります。これらは、データベースと通信するメインアプリの外部で実行されている分離されたワーカーデーモンです。サーバー名を変更して、それらが何であるかを説明する以下のprocesslist出力にコピーしました。

+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 13 | rdsadmin | localhost:43513 | mysql | Sleep | 14 | | NULL |
| 15 | proddbuser | app-server-1.eu-west-1.compute.internal:36460 | proddb | Sleep | 46 | | NULL |
| 451 | proddbuser | app-server-1.eu-west-1.compute.internal:55512 | proddb | Sleep | 29 | | NULL |
| 912 | proddbuser | app-server-1.eu-west-1.compute.internal:45171 | proddb | Sleep | 13 | | NULL |
| 941 | proddbuser | app-server-1.eu-west-1.compute.internal:47353 | proddb | Sleep | 53 | | NULL |
| 951 | proddbuser | app-server-1.eu-west-1.compute.internal:48014 | proddb | Sleep | 37 | | NULL |
| 1009 | proddbuser | app-server-1.eu-west-1.compute.internal:51787 | proddb | Sleep | 36 | | NULL |
| 1041 | proddbuser | app-server-1.eu-west-1.compute.internal:53777 | proddb | Sleep | 14 | | NULL |
| 1572 | proddbuser | app-server-1.eu-west-1.compute.internal:42989 | proddb | Sleep | 3 | | NULL |
| 1592 | proddbuser | app-server-1.eu-west-1.compute.internal:43279 | proddb | Sleep | 162 | | NULL |
| 2909 | proddbuser | app-server-1.eu-west-1.compute.internal:37768 | proddb | Sleep | 35 | | NULL |
| 3028 | proddbuser | app-server-1.eu-west-1.compute.internal:42568 | proddb | Sleep | 5 | | NULL |
| 3119 | proddbuser | app-server-1.eu-west-1.compute.internal:46913 | proddb | Sleep | 76 | | NULL |
| 3189 | proddbuser | app-server-1.eu-west-1.compute.internal:51466 | proddb | Sleep | 5 | | NULL |
| 3216 | proddbuser | app-server-2.eu-west-1.compute.internal:44097 | proddb | Sleep | 14552 | | NULL |
| 3218 | proddbuser | app-server-2.eu-west-1.compute.internal:44099 | proddb | Sleep | 14552 | | NULL |
| 3219 | proddbuser | app-server-2.eu-west-1.compute.internal:44107 | proddb | Sleep | 44 | | NULL |
| 3220 | proddbuser | app-server-2.eu-west-1.compute.internal:44113 | proddb | Sleep | 26 | | NULL |
| 3223 | proddbuser | app-server-2.eu-west-1.compute.internal:44184 | proddb | Sleep | 50 | | NULL |
| 3224 | proddbuser | app-server-2.eu-west-1.compute.internal:44187 | proddb | Sleep | 1 | | NULL |
| 3226 | proddbuser | app-server-2.eu-west-1.compute.internal:44208 | proddb | Sleep | 33 | | NULL |
| 3229 | proddbuser | app-server-2.eu-west-1.compute.internal:44250 | proddb | Sleep | 14 | | NULL |
| 3232 | proddbuser | app-server-2.eu-west-1.compute.internal:44279 | proddb | Sleep | 26 | | NULL |
| 3233 | proddbuser | app-server-2.eu-west-1.compute.internal:44297 | proddb | Sleep | 31 | | NULL |
| 3237 | proddbuser | app-server-2.eu-west-1.compute.internal:44334 | proddb | Sleep | 27 | | NULL |
| 3239 | proddbuser | app-server-2.eu-west-1.compute.internal:44338 | proddb | Sleep | 11 | | NULL |
| 3241 | proddbuser | app-server-2.eu-west-1.compute.internal:44356 | proddb | Sleep | 26 | | NULL |
| 3260 | proddbuser | app-server-2.eu-west-1.compute.internal:44619 | proddb | Sleep | 8 | | NULL |
| 3337 | proddbuser | utility-server-1.eu-west-1.compute.internal:45193 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 309416 LIMIT 1 |
| 3419 | proddbuser | utility-server-1.eu-west-1.compute.internal:46136 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 284530 LIMIT 1 |
| 3463 | proddbuser | app-server-1.eu-west-1.compute.internal:59619 | proddb | Sleep | 9406 | | NULL |
| 3504 | proddbuser | utility-server-1.eu-west-1.compute.internal:47063 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 260571 LIMIT 1 |
| 3577 | proddbuser | app-server-1.eu-west-1.compute.internal:34394 | proddb | Sleep | 6734 | | NULL |
| 3585 | proddbuser | utility-server-1.eu-west-1.compute.internal:47990 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 |
| 3664 | proddbuser | utility-server-1.eu-west-1.compute.internal:48909 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 201525 LIMIT 1 |
| 3716 | proddbuser | app-server-2.eu-west-1.compute.internal:56301 | proddb | Sleep | 27 | | NULL |
| 3748 | proddbuser | utility-server-1.eu-west-1.compute.internal:49850 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 167839 LIMIT 1 |
| 3771 | proddbuser | my-pc:30101 | NULL | Query | 0 | NULL | show processlist |
| 3831 | proddbuser | utility-server-1.eu-west-1.compute.internal:50785 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 123228 LIMIT 1 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+

また、この期間中のサイトのトラフィックは、通常のピーク時と比較して非常に低く、ピーク時に見られる負荷の約10％であると言えます。

また、最も時間のかかるアプリデータベース呼び出しが何であるかを示す新しいレリックモニタリングがあります。アプリがdbで費やす時間の99％を占める特定の呼び出しが、次のようなidによる単純なクエリであることを示しています。

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`id` = 123 LIMIT 1

（上記のプロセスリストで実行されていたクエリとまったく同じではありません）

この操作は先週かそこらで遅くなり、リクエスト間の標準偏差が大きくなり、最大時間も秒単位で測定されています。これは、原因ではなくCPU使用率の問題の結果であると思います。

このテーブルには約80,000行あるため、それほど大きくありません。データベース内のアプリのほとんどの時間は、このテーブルのレコードの検索に費やされることが予想されます。アプリの主な機能はこれに基づいています。CPU使用率が約100％のままで、アプリサーバーから本番データベースに対して同様のクエリを数回実行しましたが、1〜2ミリ秒以内に応答します。

上記のすべてに基づいて、デバッグを進める方法がわかりません。根本的な原因となる可能性があるのはどのようなものか、そしてそれらを調査する方法について誰かがアイデアを持っているのではないかと考えました。dbサーバーを実行している基盤サーバーへのアクセスは、Amazon RDSインスタンスなので制限されています。

これを解決するために、これらは私が従った手順です：

まず、ディスカッションフォーラムに投稿してAmazon RDSチームに連絡しました。mysqldプロセスがこのCPUをすべて使用していることを確認しました。

次に、実行中のクエリのソースを追跡しました。

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 

私はもともとこれを原因として見落としていました。これは、show processlistの出力を監視したときに、これらのクエリのどれも特に時間がかかっていないようだったからです。他の手段を使い果たした後、フォローアップする価値があると判断しました。

show processlistの出力でわかるように、これらのクエリは、メインアプリケーションコードの外部に存在する戦術的なユーティリティジョブを実行するユーティリティサーバーから送信されていました。これが、新しいレリックエージェントがメインアプリサーバーにのみインストールされているため、新しいレリックモニタリングでそれらが遅く表示されたり問題を引き起こしたりしなかった理由です。

このガイドにざっと従います：

http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/

これらのクエリを、ユーティリティサーバーボックスで実行中の特定のプロセスにトレースすることができました。これは、約70,000件のレコードを非常に非効率的に繰り返し、一部のフィールド値をチェックし、それらを使用して「mytable」に新しいレコードを作成する必要があるかどうかを決定するルビーコードでした。いくつかの分析を行った後、決定できましたが、プロセスは不要になったため、強制終了できました。

さらに悪いことに、cronジョブの設定方法と各プロセスにかかった時間のために、この同じプロセスのインスタンスが同時に6つ実行されているように見えました。これらのプロセスを強制終了しましたが、CPU使用率は100％から5％にまで低下しました。