MySQL（RDS）サーバーでの高IOPSの背後にある理由を見つける
AWS RDSインスタンス（MySQL 5.6を実行）でパフォーマンスの問題があります。
これは、Tigaseと呼ばれるXMPPサーバーへのバックエンドデータベースです。 Tigase Inc.によると、このタイプのdbインスタンスは、現在よりも少なくとも1桁多いトラフィックを処理できるはずです。 dbがボトルネックになることは非常にまれです。通常、Tigaseサーバーは、dbが実行する前にボトルネックになります。
AWSマネジメントコンソールでモニタリングデータを見ると、問題は主にCPUと書き込みIOPSであることがわかります。読み取りIOPSはごくわずかです。
私はティガセを書いていないので、高負荷の理由を知るのは難しいです。したがって、私の質問は次のとおりです。この背後にある根本的な原因であるクエリや構成設定を見つけるにはどうすればよいですか？どのツールを使用することをお勧めしますか？私はかなり広範なDBAの経験がありますが、MySQLに関しては初心者です。
以下は、MySQL Workbenchのパフォーマンスダッシュボードのスクリーンショットです。
ありがとう！
表示されているRDS統計は、「負荷の増加に誰が責任を負うのか？」という質問に対する回答を提供するには広すぎ、広すぎる。
クエリのプロファイリングにはいくつかの方法がありますが、MySQL 5.6でRDSを使用している場合、外部ソフトウェアは必要ないため、PERFORMANCE_SCHEMAを使用して簡単に実行することをお勧めします（一部は完全ではありません） RDS互換）。ここに IOPSやクエリパターン、ユーザー、テーブルによる一時テーブルの作成の監視などの例を含む、クエリプロファイリングの概要を説明したビデオ があります。より具体的なガイド（特にメトリックの構成）については、 公式マニュアル および sysスキーマのドキュメント を参照してください。
簡単なチェックのために、SHOW GLOBAL STATUS like 'com\_%';とSHOW GLOBAL STATUS like 'Hand%';を時間間隔で見て、単位時間あたりのSQLクエリの数またはエンジン行の数が増加していないかどうかを確認することもできます単位時間あたりの操作数（最初の操作は、示されているグラフによると異常に見えません）。
目的は、問題のあるクエリを最初に検出して、SQL、データ構造、MySQL構成、および/または周辺機器（RDSインスタンスがまだ十分である場合など）を適宜変更できるようにすることです。書き込みIOPSの増加は通常、追加のSQL負荷を意味します（明らかに）だけでなく、次のような他の多くのことも意味します。 。アクションを実行する前に、根本的な原因を特定することが重要です。
書き込みIOPSを決定する2つの最も重要なパラメーターを変更する必要があります。
1）-innodb_flush_log_at_trx_commit（0 or 2）[デフォルト値は1で比較的遅い]
2に設定すると何が起こるか（そして、パフォーマンスが向上する理由）は、変更をより長い間バッファリングするだけで、より多くのIO要求のマージとパフォーマンスの向上が得られます。それは作成されません。より多くの仕事。
2）-sync_binlog（0）[デフォルト値は1]
バイナリロギングを有効にしてサーバーを実行すると、パフォーマンスが若干低下します.sync_binlogを0に設定すると、OSがコミットグループをディスクにフラッシュします（独自の時間に）。