Cloud SQL for MySQL のパフォーマンス キャプチャは、システム需要の増加によって発生する MySQL データベースの複雑で一時的なパフォーマンスの問題を診断して解決するのに役立ちます。アプリケーション ワークロードがスケーリングされ、周辺インフラストラクチャが複雑化するにつれて、データベースに対する要求は増大し、予測不可能になります。このような外部システムの負荷により、データベースの速度低下や停止が発生する可能性があります。
データベースのパフォーマンスが低下した場合、標準指標では、より大きなインフラストラクチャのコンテキストで根本原因を特定するのに十分でない可能性があります。パフォーマンス キャプチャは、問題が検出された瞬間のデータベースの詳細なポイントインタイム スナップショットをキャプチャすることで、この問題を解決します。構成可能なトリガーを使用して、一時的な問題が発生したときにシステム全体のスナップショットを作成できます。トリガーは、パフォーマンスの問題の根本原因となる長時間実行トランザクションを検出することもできます。トリガーを構成して、長時間実行されているトランザクションを自動的に終了できます。
サンプル ユースケース
このセクションでは、インスタンスでパフォーマンス キャプチャを有効にした後に使用できるユースケースの例を示します。
| ユースケース | トリガー条件 | 診断的インサイト |
|---|---|---|
| アンドゥログの蓄積によるシステム全体の速度低下 | 履歴リストの長さ | 実行時間の長い読み取りや大規模なデータ操作言語（DML）オペレーションにより、InnoDB パージ プロセスが遅延している場合を特定します。この遅延により、ストレージの負荷が増加し、パフォーマンスが低下する可能性があります。 |
| 内部エンジン競合が原因のデータベースの停止 | セマフォの待機 <0x0 | 応答しないデータベースの診断に役立ちます。このトリガーは、InnoDB ストレージ エンジン内のミューテックスまたは読み取り / 書き込みロックの競合（アダプティブ ハッシュ インデックス（AHI）やバッファプールの競合など）を検出できます。 |
| アプリケーション レベルのロック競合またはインデックスなしのクエリ | トランザクション ロックの待機 | 多数のトランザクションが LOCK WAIT 状態の場合にトリガーされ、行レベルの競合または長時間実行されるアイドル状態のトランザクションを示します。 |
| 複雑な並べ替えや集計によるインスタンスの過負荷 | CPU 使用率が高い | 高状態をキャプチャします。コンテナの CPU 使用率が高い状態です。多くの場合、非効率的なクエリや同時実行数の急増が原因です。 |
| メモリ不足（OOM）による再起動のリスク | メモリ使用量が多い | インスタンスのクラッシュにつながる前に、スレッドあたりのバッファのサイズ超過やメモリリークなどの問題を診断するのに役立ちます。 |
| トラフィックの急増またはボトルネック状態のクライアント アプリ | 実行中のスレッド | インスタンスの負荷の一般的な指標。同時アクティブ接続の急増を特定するのに役立ちます。 |
| 書き込みワークロードが重いため、レプリカのデータが古い | ソースからの遅れ秒数 | リードレプリカのレプリケーション ラグをモニタリングして、プライマリ インスタンスからのデータの同期の遅延を診断します。 |
| 削除をブロックする長時間実行クエリ | 長時間実行トランザクション | オープン状態が長すぎて、重要なロックを保持している可能性があるトランザクションを特定します。また、長時間実行されているトランザクションを自動的に終了することもできます。 |
パフォーマンス データの取得方法
パフォーマンス キャプチャは、インスタンスをモニタリングするエージェントベースのサービスとして動作します。パフォーマンス キャプチャを有効にすると、Cloud SQL インスタンスは次の処理を行ってパフォーマンス データをキャプチャします。
エージェントはインスタンス構成をプローブして、定義したしきい値ベースのトリガーを読み取ります。エージェントは、構成可能な間隔
probingIntervalSecondsでインスタンスの指標をプローブします。デフォルトでは 30 秒に設定されています。問題が検出され、トリガーのしきい値を超えると、エージェントはインスタンスのライブ状態とルールを比較し続けます。一時的なスパイクによる誤ったアラームを防ぐため、エージェントはパフォーマンスの完全なキャプチャをトリガーします。キャプチャは、構成された
probeThreshold（デフォルトは3）の連続するプローブ中に条件が満たされた場合にのみトリガーされます。この連続しきい値により、一時的なスパイクによるキャプチャを防ぐことができます。たとえば、エージェントは、3 回連続でプローブでスレッド数が多いことを検出した場合に、パフォーマンス キャプチャをトリガーすることがあります。
複数のトリガー条件が構成されている場合、Cloud SQL は、条件のいずれかが満たされるとキャプチャを開始します。
キャプチャがトリガーされると、パフォーマンス キャプチャはデータベースに接続し、一連の診断コマンドを実行して詳細なスナップショットをキャプチャします。
キャプチャされた情報はログエントリにフォーマットされ、
mysql-performance-capture.logという名前の特定のログストリームの下にある Cloud SQL インスタンスのプロジェクトの Cloud Logging に直接送信されます。
クールダウン期間とアダプティブ バックオフ期間
過剰なロギングとシステム オーバーヘッドを防ぐため、パフォーマンス キャプチャではキャプチャ後にクールダウン期間が実装されています。
標準クールダウン
キャプチャが成功すると、パフォーマンス キャプチャは 30 分間の標準クールダウンを開始します。この間、インスタンスが問題の拡張状態にあっても、エージェントは新しいキャプチャをトリガーしません。
アダプティブ クールダウンとバックオフ
インスタンスが同じ違反に対してキャプチャを繰り返しトリガーすると、パフォーマンス キャプチャは適応型クールダウン バックオフ メカニズムを使用します。このメカニズムは、誤って構成されたしきい値のロギング量とコストを制限するのに役立ちます。
このメカニズムでは、次のようになります。
- クールダウンは 24 時間に延長されます。
- パフォーマンス キャプチャがスリープモードに入り、すべてのトリガー チェックと診断キャプチャが一時停止します。
- インスタンスは 1 日に 1 回のパフォーマンス キャプチャに制限されます。
パフォーマンス キャプチャ トリガー
このセクションでは、MySQL パフォーマンス キャプチャで使用できるトリガーについて説明します。表に記載されているすべてのトリガーは、注記がある場合を除き、プローブ構成値 probingIntervalSeconds と probeThreshold を使用して、持続トリガー条件を検証します。
| トリガー 条件 名前 | API 名 | 説明 | デフォルト 値 | 構成 範囲 |
|---|---|---|---|---|
| CPU 使用率が高い |
cpuUtilizationThresholdPercent
|
データベース インスタンスの CPU 使用率がこの割合を継続的に超えた場合にキャプチャをトリガーします。これにより、インスタンスの過負荷を検出できます。インスタンスの過負荷は、大量の並べ替えと集計を伴う非効率的なクエリ、インデックス作成の不足、非常に高い同時実行性が原因で発生することがよくあります。小さなスパイクでのキャプチャを回避するには、インスタンスの割合が高い範囲になるようにデフォルトを構成します。 | 0（無効）
|
0、または 10～99（%）
|
| メモリ使用量が多い |
memoryUsageThresholdPercent
|
データベース コンテナのメモリ使用量が、インスタンスの割り当てメモリのこの割合を継続的に超えた場合に、キャプチャをトリガーします。このトリガーは、メモリ不足の問題、メモリリーク、メモリ構成の非効率性を診断するのに役立ちます。小さなスパイクをキャプチャしないようにするには、インスタンスの範囲の上限にデフォルトを設定します。 | 0（無効）
|
0、または 10～99（%）
|
| 一時ファイルの使用量が多い |
構成できません。このトリガーは、MySQL 8.0 以降で自動的に有効になります。 | MySQL プロセスによって作成された一時ファイルからのディスク使用量が大幅に増加した場合に、キャプチャを自動的にトリガーします。一時ファイルは削除されることが多いですが、MySQL プロセスによってまだ開かれています。 このトリガーのしきい値は、差分しきい値の段階的なエスカレーション モデルを使用します。100 GB から始まり、クールダウンごとに 200 GB、400 GB、1.6 TB と順に倍増します。プログレッシブ エスカレーション モデルを使用すると、一時ファイルの使用量の差が大幅に増加した場合にのみ、パフォーマンスのキャプチャが行われます。 |
有効 <0x0 | 該当なし <0x |
| 履歴リスト の長さ |
historyListLengthThresholdCount
|
InnoDB 履歴リストの長さ（HLL）が構成された値を超えると、キャプチャをトリガーします。HLL が高い状態が続いている場合は、InnoDB パージ プロセスが追いつかず、パージされていないトランザクションの数が増加していることを示します。これは、長時間実行されているトランザクションが原因であることがよくあります。この数値が大きいと、ストレージ使用量の増加やパフォーマンスの問題につながる可能性があります。 このしきい値はワークロードによって異なります。一部のインスタンスは、HLL が常に高い状態でも十分に動作します。ただし、このトリガーを使用して、長時間実行される読み取り、大規模なデータ操作言語（DML）ステートメント、パージ スレッドのボトルネックなどの潜在的な問題をハイライト表示することはできます。 |
0（無効）
|
0、または 10000-10000000
|
| 長時間実行トランザクション |
transactionDurationThreshold
|
トランザクションが構成された秒数よりも長く実行された場合、トランザクションがログに記録されます。このトリガーは、ロックを過度に保持している可能性のあるオペレーションや、リソースを過度に消費しているオペレーションを特定するのに役立ちます。transactionDurationThreshold を超えるトランザクションは、probingIntervalSeconds 構成で指定された各間隔（デフォルトは 30 秒）の後に評価されます。ただし、ログの量を管理するため、これらの長時間実行トランザクションのうち最大 10 件の詳細が、クールダウン期間（30 分）ごとに最大 1 回 Cloud Logging に送信されます。INFORMATION_SCHEMA.INNODB_TRX からの最大 1,024 バイトのクエリ テキスト全体が、上位 10 件のトランザクションの各ログエントリに含まれます。 |
3600（秒）
< |
60 以上
<0x |
| レプリカ SQL/IO スレッド エラー |
構成できません。このトリガーは、すべてのレプリカ インスタンスでデフォルトで自動的に有効になり、無効にすることはできません。 | レプリカ インスタンスのレプリケーション SQL スレッドまたは IO スレッドでエラーが発生して停止した場合、キャプチャを直ちにトリガーします。このトリガーは、レプリカの完全性を維持し、レプリケーション エラーを特定するために重要です。 このトリガーは、 probingIntervalseconds や probeThreshold などのプローブ構成設定を使用してパフォーマンス キャプチャ条件を検証しません。 |
有効 <0x0 | なし <0x0 |
| 実行中のスレッド < | runningThreadsThreshold
|
threads_running ステータス変数に基づいて実行されているアクティブ スレッドの数が指定された値を超えると、キャプチャをトリガーします。たとえば、アクティブな実行スレッドの数が 100 を超えた場合にパフォーマンス キャプチャを実行するようにしきい値を構成できます。このトリガーはパフォーマンスのキャプチャに必要です。このトリガーを明示的に構成しない場合、デフォルトはインスタンスに属する vCPU の数に基づいて計算されます。 |
MIN(600,
cpuCount * 20)
|
10 以上
|
| ソースからの遅れ秒数 |
secondsBehindSourceThreshold
|
読み取りレプリカ インスタンスのレプリケーション ラグ（秒単位）が指定された値を超えると、キャプチャをトリガーします。このトリガーを使用して、レプリケーションの遅延をモニタリングして診断できます。このトリガーは、レプリカ インスタンスで自動的に有効になります。トリガーを明示的に構成しない場合、デフォルトは 900 秒です。過剰なキャプチャと頻繁なクールダウンを避けるため、値を大きめに設定することをおすすめします。 | 900（秒）
|
1 以上
|
| セマフォの待機 <0x0 | semaphoreWaitThresholdCount
|
内部 InnoDB セマフォで待機しているスレッドの数が、このトリガーの構成値を超えたときにキャプチャをトリガーします。この高度な指標は、InnoDB ストレージ エンジン自体内のミューテックスまたは読み取り / 書き込みロックを使用して、競合を示します。通常、Adaptive Hash Index（AHI）の競合、バッファプール競合、ディスク IO 競合が発生します。 このトリガーの構成値に関係なく、単一のセマフォの最大待機時間が 200 秒を超えた場合もキャプチャがトリガーされます。 |
0（無効）
|
0、または 10-10000
|
| トランザクションのロック待機 |
transactionLockWaitThresholdCount
|
LOCK WAIT 状態のトランザクションの数が構成された数を超えると、キャプチャをトリガーします。ロック待機状態のトランザクションが少数であれば、ビジー状態のシステムでは正常な場合がありますが、ロック待機が常に多い場合は、アプリケーション レベルのロック競合、インデックスなしの DML、アイドル状態の長いトランザクション、高コンカレンシーの行競合の強い兆候であり、パフォーマンスとスループットが大幅に低下する可能性があります。 |
0（無効）
|
0、または 10-10000
|
料金
パフォーマンス キャプチャは、Cloud SQL のすべてのリージョンで追加費用なしで利用できます。標準料金は、基盤となるデータベース リソースにのみ適用されます。パフォーマンス キャプチャはログを Cloud Logging に保存するため、Cloud Logging のストレージ費用が追加で発生する可能性があります。
Logging にログを保存する料金の詳細については、料金をご覧ください。
制限事項
- パフォーマンス キャプチャを使用するには、Query Insights を有効にする必要があります。Query Insights を無効にすると、パフォーマンス キャプチャも無効になります。
- パフォーマンス キャプチャは、Cloud SQL for MySQL 5.7 以降でのみ使用できます。