PolarDB-X ベストプラクティス (4): コア監視メトリクス

> 本記事は[こちらのブログ](https://www.alibabacloud.com/blog/polardb-x-best-practices-4-core-monitoring-metrics_602035?spm=a2c65.11461433.0.0.4ee35355zOUPsx)を参考にしています。
> 翻訳にはアリババクラウドの[ModelStudio](https://www.alibabacloud.com/en/product/modelstudio)([Qwen](https://www.alibabacloud.com/en/solutions/generative-ai/qwen))を使用しております。

# PolarDB-X のコア監視指標について

Mengshi による寄稿

[PolarDB-X](https://www.alibabacloud.com/product/polardb-for-xscale) は、CN（Compute Node）、DN（Data Node）、GMS（Global Metadata Service）、CDC（Change Data Capture）などのコンポーネントで構成される分散データベースです。その監視ページには多くの監視指標があります。実際、ほとんどのデータベースは膨大な監視指標を提供していますが、これらの指標を使用する経験がないと混乱しやすいです。ほとんどの指標は、極端なトラブルシューティングのシナリオなど、稀なケースでのみ役立ちます。通常、データベースの運用状態を把握するために注目すべきは、ほんの数個の重要な指標だけです。この記事では、[PolarDB-X](https://www.alibabacloud.com/product/polardb-for-xscale) のコア監視指標について説明します。また、ここで紹介する洞察は MySQL エコシステム内の他のデータベースにも適用可能です。

## コンピューティングリソース (CN)

### CPU
CN にとってのコアリソースは CPU であり、最も重要な監視指標は CPU 使用率（Computing Resource Monitoring -> Instance -> CPU）です：
![1](https://yqintl.alicdn.com/8cc0e08858419b03a2ce516a56b7e9ab599ac0d2.jpeg)

CPU リソースが不足している場合は、CN の仕様をアップグレードするか、CN の数を増やすことをお勧めします。

### メモリ
PolarDB-X の CN は Java で実装されたプログラムであり、メモリ使用率は JVM ヒープメモリの OLD 領域の使用状況を示します。Java はガベージコレクション（GC）メカニズムを使用してメモリを回収するため、メモリ監視（Computing Resource Monitoring -> Cluster -> Memory）グラフは通常、以下のようにジグザグのパターンを示します。これは正常な状態であり、心配する必要はありません。
![2](https://yqintl.alicdn.com/0de878a2189f931a29344225c5dd9c9e89de5555.jpeg)

ただし、メモリ使用率のみを監視しても、CN に十分なメモリがあるかどうかを判断することはできません。一般的には、Full GC 時間（Computing Resource Monitoring -> Cluster -> Full GC Time）と組み合わせて監視することをお勧めします。
![3](https://yqintl.alicdn.com/470e3e357d89e90eb57422b3016fac9a29f6f458.jpeg)

Java に詳しくない方のために説明すると、Full GC とはメモリが不足した際に発生する GC 動作です。言い換えれば、メモリが十分にある場合、Full GC 時間は常に 0 になるはずです。この指標が短時間内に頻繁に非ゼロ値を示す場合、通常それはメモリが不足していることを意味します。以下のような対応策があります：

- CN の仕様をアップグレードする。
- SQL 文を最適化する。以下の種類の SQL 文は大量のメモリを消費することがあります。SQL Explorer などの機能を使ってさらに分析できます：
  - 極めて大きなバッチ挿入操作。
  - 多数の中間結果を生成する集計操作（例：GROUP BY、DISTINCT 操作）。
  - シャード間の結合操作。

### 論理 QPS と物理 QPS
論理 QPS（Computing Resource Monitoring -> Node -> Logical QPS）とは、CN 層における QPS を指します。一方、物理 QPS（Computing Resource Monitoring -> Node -> Physical QPS）とは DN 層における QPS を指します。例えば、ある SQL 文が 10 のシャードをクエリする必要がある場合、CN 層では 1 クエリとして記録され、DN 層では 10 クエリとして記録されます。ほとんどの場合、物理 QPS は論理 QPS 以上になります。（稀なケースでは逆の場合もあります。例えば、テーブル名を持たない一部の SQL 文が CN によって処理される場合など。）

QPS にはクエリ操作と DML 操作が含まれます。これら二つの指標は有用です。ベストプラクティスを一言でまとめると次のようになります：

> **PolarDB-X のパフォーマンスと拡張性は、物理 QPS : 論理 QPS の比率が 1:1 に近いかどうかに大きく依存します。**

物理 QPS が論理 QPS を大幅に上回る場合（例：テーブルが 16 シャードに分割されている場合、物理 QPS : 論理 QPS = 16:1）、これは、ほとんどのクエリがパーティションキーを持たず、フルシャードスキャンを行っている可能性を示唆します。比率が 1:1 に近い場合、ほとんどの SQL 文はパーティションキーに関する等価条件を持っていることを意味します。ただし、この比率が必ずしも 1:1 である必要はありません。グローバルインデックスの書き込みやバッチ挿入などの操作はこの比率を増加させることがありますが、これは正常です。

**注意:** PolarDB-X の QPS では、ユーザーの実際の体験に近いデータを提供するために以下の文が除外されています：
1. `SELECT 1` （通常、接続プールが接続の生存確認のために送信します）。
2. `SELLECT @@xxxxxx, @@xxxxxx, @@xxxxx` （通常、mysql-java-connector が接続を作成する際に生成します）。
3. トランザクション制御文（例：commit、rollback、begin、set autocommit=0）。
4. Prepare プロトコルの prepare セクション。
5. その他、通常業務で生成されない文（例：一部の SHOW コマンドなど）。

## ストレージリソース (DN)

### CPU
CPU は重要なリソースなので、アラート項目を設定することをお勧めします。CPU リソースが不足した場合：

- SQL 文を最適化する。
- DN の仕様をアップグレードする。
- DN の数を増やす。

### メモリ
DN にはいくつかのメモリ関連の指標があります。

#### メモリ使用率
CN のメモリ使用率とは異なり、DN のメモリ使用率（Storage Resource Monitoring -> Node -> Memory Usage）は、DN プロセスが使用するメモリ量と物理メモリ量の比率を指します。DN 内のメモリは主にバッファープール（通常、メモリの 75% 以上）に使用されます。バッファープール用のメモリは、DN プロセスの起動時に事前に割り当てられ、トラフィックには影響されません。そのため、メモリ使用率の監視では、長期間にわたって 90% 以上の使用率が維持されるのが普通です。これは正常であり、特に問題ではありません（アイドル状態のメモリは DN にとっては無駄です）。したがって、DN のメモリについては、バッファープールに関連する監視を直接観察します。

#### メモリバッファープール
バッファープール（Storage Resource Monitoring -> Node -> Memory Buffer Pool）の監視グラフには、次の三つの主要な指標が含まれます：

- バッファープールの読み取りヒット率。
- バッファープール内のダーティブロック数。
- バッファープールの使用状況。

この中で最も重要な指標は、バッファープールの読み取りヒット率です。データベースの原理に詳しくない場合でも、SQL 文はすべてのデータの読み書きをバッファープールを通じて行うということだけ覚えておいてください。バッファープールに存在しないデータの場合、ディスクからバッファープールに読み込む必要があります。メモリの読み書きに比べて、ディスク I/O は高コストで効率の低いリソースです。多くのデータベースの最適化は、最終的にディスク I/O を削
# コンポーネントとCloudMonitorでのメトリック名および推奨アラートしきい値

| コンポーネント | CloudMonitorでのメトリック名 | 推奨アラートしきい値 |
|----------------|-------------------------------|-----------------------|
| CN（計算リソース） | PolarDB-X コンピュートノードのCPU使用率 | 70% |
| DN（ストレージリソース） | PolarDB-X データノードのCPU使用率 | 70% |
|  | PolarDB-X データノードのIOPS使用率 | 70% |
|  | PolarDB-X データノードのディスク使用率 | 85% |
| CDC（Change Data Capture） | PolarDB-X CDC DumperのCPU使用率 | 70% |
|  | PolarDB-X CDC Dumperのレイテンシ | 10秒 |

**注意:**  
本記事で言及されていないメトリックは通常、アラートルールを設定する必要はありませんが、これらのメトリックが無意味であることを意味するものではありません。トラブルシューティングなどのシナリオでは、これらのメトリックも参考になる場合があります。