Amazon Aurora MySQL で Performance Schema の有効・無効による Performance Insights で表示される情報の違い

AWS

2022.12.26

Topics

はじめに

パフォーマンススキーマを有効化している状態とそうでない場合では Performance Insights で見れるモニタリング内容が異なります。
本記事ではそれらについて解説します。

表記について

「Performance Insights」 と 「Performance Schema」は文字列が似ていてややこしいです。
そのため本記事では、「Performance Insights」 を英語表記で、「パフォーマンススキーマ」をカタカナ表記にしています。

環境について

本記事では、Aurora MySQL v2(5.7 互換) で検証をしています。
他環境・バージョンによっては、表示される内容が違う可能性があるのでご注意ください。

Performance Insights・パフォーマンススキーマの概要

まずは、「Performance Insights」と「パフォーマンススキーマ」について少し解説します。
それぞれの機能は独立していますが、相互に関係のある機能となっています。

Performance Insights について

RDS には、Performance Insights というデータベースパフォーマンスのチューニングとモニタリングを行う機能があります。
Performance Insights(RDS のパフォーマンスを分析、チューニング)| AWS

Performance Insights を使うメリットは以下です。

  • 負荷を発生させている SQL ステートメントとその理由を簡単に調べられる
  • データベースの負荷が可視化される
  • 無料で 7 日間のパフォーマンス履歴を保存・分析できる
  • 設定もメンテナンスも不要で簡単に有効化できる

Performance Insights で主に3つのセクションに分かれています。

  • カウンターメトリクス
  • データベース負荷
  • ボトルネックの分析軸

パフォーマンスインサイトのセクション説明

パフォーマンススキーマについて

MySQL には、パフォーマンススキーマという MySQL サーバーの実行をモニタリングするための機能があります。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 27 MySQL パフォーマンススキーマ

パフォーマンススキーマはサーバーイベントをモニターしてくれます。
イベントとは、時間を消費し、タイミング情報を収集できるように実装されたデータベースサーバーアクションです。
イベントの例には、以下のようなものがあります。

  • 関数呼び出し
  • オペレーティングシステムの待機
  • SQL 実行のステージ
  • SQL ステートメントのグループ

パフォーマンススキーマ有効・無効による Performance Insights の違い

パフォーマンススキーマの有効・無効の違いとして基本的に得られる情報の粒度や種類が異なります。
パフォーマンススキーマを有効化にしたほうがよりよいデータでパフォーマンス分析ができるので推奨します。
それぞれの有効化手順については最後に記述しているのでご覧ください。

今回解説する違いは以下の3つです。

  • 待機イベントとスレッド状態
  • SQL の情報粒度
  • 接続先 DB

では、それぞれの詳細について見ていきます。

待機イベントとスレッド状態

「ボトルネックの分析軸」でトップ待機を確認することができます。
これは、どの SQL がどのイベントの種類で待機しているのかを確認できる項目となっています。

パフォーマンススキーマ無効の場合は、スレッドの状態が表示されます。
そのため、どのクエリがなにで負荷が高かったのかについてはあまり情報を得ることができません。

スレッド状態

待機イベントとスレッド状態では、見れるサーバー情報や粒度が異なるため、分析を行う上では待機イベントを見れるほうが良いと考えます。

  • 待機イベント
    • 待機イベントはセッションが待っているリソースを示します
    • 表示される内容:io/socket/sql/client_connection
    • 待機イベント
  • スレッド状態
    • 一般的なスレッド状態は State 一般的なクエリ処理に関連付けられている値です
    • 表示される内容:sending data
    • Aurora MySQL スレッド状態

待機イベントやスレッド状態の詳細については MySQL ドキュメントをご覧ください。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.14.3 一般的なスレッドの状態
MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.18.1 待機イベント要約テーブル

ちなみに、AWS が公開しているチューニング方法の数は待機イベントが圧倒的多いです。

  • 待機イベント:14 種類
  • スレッド状態:2 種類

待機イベントを使用した Aurora MySQL のチューニング – Amazon Aurora
スレッド状態を使用した Aurora MySQL のチューニング – Amazon Aurora

パフォーマンススキーマ有効の場合は、 待機イベントが表示されます。
この待機イベントで、よりイベントにフォーカスをして何が原因だったのかを追うことができます。
待機イベント

例えば、cpu 待機イベントは、スレッドが CPU でアクティブな場合、または CPU を待っている際に発生します。
待ち時間増加の考えられる原因としては、「実行時間が長いトランザクション」や「接続数の急激な増加」などが考えられます。

AWS ドキュメントを見ればそのイベントに対する対応アクションなどが確認できるのでパフォーマンス分析する際にご覧ください。
cpu – Amazon Aurora

SQL の情報粒度

「ボトルネックの分析軸」でトップ SQL を確認することができます。
これは、どの SQL がどれぐらいの負荷があるのかを確認できる項目となっています。

パフォーマンススキーマ無効の場合は、その SQL がどれぐらい行を読み込んだのかやどれぐらい時間がかかったのかの情報が表示されません。
そのため、どのクエリがなぜ負荷が高かったのかについてはあまり情報を得ることができません。

以下画像の「Calls/sec」、「Avg latency (ms)/call」、「Rows examined/call」にはなにも表示されていません。

表示されていないSQL情報

トップ SQL では、全部で 33 の項目で SQL を分析することができます。
この中には、「Rows examined」や「Select full join」など、そのクエリが本当にパフォーマンスの悪い動作をしているかの指標となる値を表示してくれます。
SQLで見れる項目一覧

パフォーマンススキーマ有効の場合は、33 の項目すべてが表示されます。

33 の項目を見て、改善したほうが良いクエリを確認することができます。

SQL詳細情報が表示されている

接続先 DB

「ボトルネックの分析軸」で上位データベースを確認することができます。
これは、どの データベースに対しての負荷があるのかを確認できる項目となっています。

一つの RDS 内で複数のデータベースを使い分けている場合は、データベースごとの分析に活用できます。

パフォーマンススキーマ無効の場合は、Database が表示されません。
そのため、別々のデータベースに接続しても「Unknown」に統合されます。

上位データベースが表示されていない

パフォーマンススキーマ有効の場合は、Database が表示されます。

一部隠しているので分かりづらいかもしれませんが、「Unknown」ではなく適切なデータベース名が表示されています。

上位データベースで表示されているデータベース

Performance Insights・パフォーマンススキーマ有効化手順

上記で解説したように、パフォーマンススキーマは有効化した状態をオススメします。
そのため、以下にてそれぞれの手順を少し解説します。

なお、有効化手順で以下情報がいちばん大切なので先に記述します。

Performance Insights は有効化・無効化でインスタンスの再起動は必要ないですが、パフォーマンススキーマの場合はインスタンスの再起動が必要です。

なので、可能なら DB インスタンス構築時から Performance Insights を有効化することをオススメします。
また、AWS の推奨設定は、パフォーマンススキーマと Performance Insights を有効にした状態で、Performance Insights がパフォーマンススキーマを自動的に管理する状態としております。
DB インスタンス構築時から Performance Insights を有効にしておけば、パフォーマンススキーマも自動的に管理となり有効化されます。

Aurora MySQL における Performance Insights の Performance Schema の有効化 – Amazon Aurora

Performance Insights 有効化

RDS > データベース > 変更と選択します。
インスタンスごとにこの項目は設定できるので、Aurora の場合はクラスターではなくインスタンスを選択してください。

モニタリング項目で「Performance Insights をオンにする」にチェックを入れます。

PerformanceInsights有効化手順

あとは、すぐに適用すれば OK です。

しばらくすると、Performance insights の画面で「メトリクスを表示する DB インスタンスを選択します」の欄に有効化したインスタンスが表示されるので選択するだけです。

PerformanceInsights選択画面

パフォーマンススキーマ有効化

Performance Insights 有効化した状態でインスタンスを再起動してください。
すると自動的にパフォーマンススキーマも有効化されます。

パフォーマンススキーマの値を確認する方法は、DB インスタンスに接続して以下を実行するのみです。
パラメータグループ値は変更されませんのでご注意ください。

SHOW VARIABLES LIKE 'performance_schema';

以下例のように、ONになっていれば大丈夫です。

MySQL [(none)]> SHOW VARIABLES LIKE 'performance_schema';

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+
1 row in set (0.03 sec)

Amazon RDS for MariaDB または MySQL における Performance Insights の Performance Schema の有効化 – Amazon Relational Database Service

まとめ

Performance Insights 自体は再起動が不要なため、あとから有効化した場合は得られる情報がかなり異なるため混乱するのではないでしょうか。
Performance Insights の機能をフル活用する場合は、インスタンスの再起動が必要なため、気をつけて素晴らしい Performance Insights ライフをお楽しみください。

Cold-Airflow

2021年新卒入社。インフラエンジニアです。RDBが三度の飯より好きです。 主にデータベースやAWSのサーバレスについて書く予定です。あと寒いのは苦手です。

Recommends

こちらもおすすめ

Special Topics

注目記事はこちら