はじめに
BLOGでは、Percona Monitoring and Management(以下PMM)については何度か取り上げてきました。
今回はPMMの機能の１つであるQuery Analytics(以下QAN)を紹介します。
なお、本記事はPMM最新リリース2.17.0の情報をもとにしています。
QANのソースについて
QANは名前の通りクエリを分析するための機能で、Slow query logまたはPerformance Schemaから取得したデータをもとにどのようにクエリが実行されたかなどの情報を表示します。
MySQLの監視サービスを追加するときに--query-sourceを使用してソースを選択します。選択できる値はslowlog(デフォルト)、perfschema、noneのいずれかです。
|
1 |
$ pmm-admin add mysql --query-source=perfschema --username=pmm --password=pass |
Slow query logとPerformance Schemaの推奨ソースについてはドキュメントには以下のように記載されています。
| データベースサーバー | バージョン | 推奨ソース |
|---|---|---|
| MySQL | 5.1-5.5 | Slow query log |
| MySQL | 5.6+ | Performance Schema |
| MariaDB | 10.0+ | Performance Schema |
| Percona Server for MySQL | 5.7、8.0 | Slow query log |
| Percona XtraDB Cluster | 5.6、5.7、8.0 | Slow query log |
製品によってSlow query logの出力は異なっていますが、MySQLやMariaDBの場合、Performance Schemaの方がPMMはより多くの情報を取得できるようです。
なお、PMM ClientはローカルのSlow query logを読み取るため、リモートインスタンスを監視する場合は、ソースをPerformance Schemaにする必要があります。
表示内容
QANの中央に表示されるのがOverview Panelです。
object type
QANでは以下のオブジェクト単位でメトリックを表示します。
- Query
- Service Name
- Database
- Schema
- User Name
- Client Host
オブジェクト名(図①)を選択すると他のオブジェクトに切り替えられます。
Metrics columns
1番最初に表示されるのがメインメトリック(図②)です。スパークラインと呼ばれるグラフ(図③)が表示されます。
それ以降にあるメトリック列は追加・削除が可能です。
メトリック列の追加はAdd column(図④)を選択し、表示されるメトリックから任意のメトリックを選択します。
メトリック名の横に使用できるDBのタグがついています。
mysqlのタグがついているメトリックは以下となります。
| メトリック名 | 説明 |
|---|---|
| Bytes Sent | すべてのクライアントに送信されたバイト数 |
| Query Count with errors | エラーのあるクエリの総数 |
| Query Count with warnings | ワーニングのあるクエリの総数 |
| Filesort | ファイルソートを使用した数 |
| Filesort on Disk | ファイルソートがディスク上で実行された数 |
| Full Join | フルジョイン（インデックスなしのジョイン）を実行した数 |
| Full Scan | フルテーブルスキャンを実行した数 |
| Innodb Read Bytes | スケジュールされたページ読み取り操作の合計(Bytes) |
| Innodb IO Read Ops | スケジュールされたページ読み取り操作の数 |
| Innodb IO Read Wait | InnoDBがストレージからデータを読み取る時間 |
| Innodb Pages Distinct | クエリがアクセスした一意のページのおおよその数 |
| Innodb Queue Wait | クエリがInnoDBキューに入るのを待つか、実行を保留するのに費やした時間 |
| Innodb Rec Lock Wait | クエリが行ロックを待機した時間 |
| Lock Time | ロックを取得する時間 |
| Merge Passes | 実行されたソートアルゴリズムに合格したマージの数 |
| No Good Index Used | 適切なインデックスのないクエリの数 |
| No index used | インデックスのないクエリの数 |
| Query Cache Hit | クエリキャッシュヒット |
| Query Length | クエリの長さ |
| Rows Affected | UPDATE、DELETE、またはINSERTによって変更された行数 |
| Rows Examined | SELECTによってスキャンされた行数 |
| Rows Read | テーブルから読み取られた行数 |
| Select Full Range Join | 参照テーブルの範囲検索を使用した結合の数 |
| Sort Range | 範囲を使用したソートの数 |
| Select Range | 最初のテーブルのレンジを使用した結合の数 |
| Select Range Check | 各行のあとにキーの使用状況がチェックされるキーなしの結合数 |
| Sort Rows | ソートされた行の数 |
| Sort Scan | テーブルをスキャンするときに実行されたソートの数 |
| Tmp Disk Tables | クエリのためにディスク上に作成された一時テーブルの数 |
| Tmp Table | 暗黙的な内部一時テーブルが作成された数 |
| Tmp Table on Disk | クエリの一時テーブルがディスクに保存された数 |
| Tmp Table Sizes | クエリで使用されるすべての一時テーブルの合計サイズ |
| Tmp Tables | クエリ用にメモリ上に作成された一時テーブルの数 |
メトリック名の横にある△▽を選択するとのその列でソートができます。
列の削除はメトリック名を選択し、Remove columnを選択すると削除されます。
また、Remove columnの下にあるSwap with main metricを選択するとそのカラムがメインメトリックとなります。
使用例の紹介
QANのソースをPerformance Schemaに設定したMySQL8.0を対象に簡単な使用例を紹介します。
今回はMySQL Instance Summary dashboardダッシュボードと連携させた使い方を紹介します。
MySQL Instance Summary dashboardにはスロークエリの回数を表示するMySQL Slow Queriesがあります。このグラフが図のように値が急上昇しているとします。このグラフからは具体的に何のクエリが実行に時間が掛かっているのかはわかりません。
こういったときはQANを使用します。PMMではダッシュボード間を移動する際には選択されているサービス名や時間範囲などは引き継がれます。QANに移動した場合も、選択していたサービス名などがフィルターとして適用された状態で表示されるため、スムーズに分析に進めます。
例えば、今回はnodeA-mysqlというService NameのDBのスロークエリを確認します。
上部のショートカットからQANに移動します。
するとService NameがnodeA-mysqlでフィルタリングされた状態で表示されます。
スロークエリの回数の急上昇について分析したいため、Query Countをメインメトリックに変更し、ソートします。
先頭行のTOTALのスパークラインを見るとMySQL Slow Queries同様、２つの山ができています。また、その下を見ていくと問題の時間帯に値が急上昇しているクエリが見つかります。
このようにして、スロークエリの特定を行えます。
また、最初に確認したMySQL Instance Summary dashboardのMySQL Select Typesというグラフでもフルテーブルスキャンの回数を表示するSelect scanの値が急上昇していました。
ためしにQANでFull scanのカラムを追加してみると、4番目のクエリがFull Scanを行っていることがわかります。
まとめ
QANではどのようなメトリクスを参照できるのかを確認しました。
参照できるメトリクスが多いですが、上手く使いこなせるとQANは強力なツールとなりそうです。
