ホストのCPU使用率が高すぎることは、データベースの運用保守においてよく見られる問題であり、通常は業務SQLによって引き起こされます。CPUリソースの枯渇は、業務の応答時間の遅延やサービスの利用不能につながるため、迅速に問題を特定し解決する必要があります。本記事では、パブリッククラウド環境下で、業務SQLが原因でホストのCPU使用率が高すぎる場合、どのようにして迅速に問題を確認し、キーレベルのSQLを特定するかについて説明します。
問題の確認
どのホストのCPU使用率が高すぎるかを確認するには、以下の2つの方法があります：
アラートの設定
OceanBase Cloudコンソールで、OceanBaseノードCPU使用率アラートを設定すると、OceanBase Cloudから、CPU使用率が高すぎるホスト（つまりOceanBaseノード）について、タイムリーに通知を受け取ることができます。アラートの設定方法については、アラート管理をご参照ください。
ホスト監視データの確認
OceanBase Cloudコンソールで、各ホストのCPU使用率監視データを確認します。CPU使用率が継続的に約95%で安定している場合、CPUリソースが枯渇していることを示しています。ホスト監視データの確認方法については、クラスタホストのパフォーマンス監視をご参照ください。
問題の特定
ホストのCPU使用率が高すぎるのは、通常、業務SQLによって引き起こされるため、調査時にはまずSQLの問題を優先的に検討する必要があります。
問題の分析
自動分析
システムは異常イベントの根本原因分析機能を提供しており、異常な時間帯にCPU占有率が高かったSQLを自動的に分析し、最適化の提案を提供します。根本原因分析機能の表示方法については、異常イベントの表示をご参照ください。
手動分析
単一テナントクラスタの場合、テナントレベルのTop SQL機能を使用すると、CPUを最も消費するSQLを特定できます。マルチテナントクラスタの場合は、クラスタレベルのTop SQL機能を使用して、問題のSQLを迅速に特定できます。
操作手順
OceanBaseクラウドサービスコンソールにログインします。
左側のナビゲーションペインで、**インスタンス**をクリックします。
インスタンスリストで対象のインスタンスを見つけ、インスタンス名をクリックして、**概要**に入ります。
左側のナビゲーションペインで**診断をクリックし、次に診断ページでリアルタイム診断**タブを選択します。
**リアルタイム診断**ページの中央部で、テナントを選択します。
単一テナントクラスタの場合、システムはデフォルトで現在のテナントを表示するため、選択は不要です。
マルチテナントクラスタの場合、**すべてのテナント**を選択します。
**SQLタブで、ノードドロップダウンリストから対象ノードを選択し、時間範囲フィルターボックスでCPU異常が発生した時間帯を選択します（データの正確性を確保するため、異常開始の少し前の期間を選択することを推奨します）。その後、クエリ**ボタンをクリックします。
**上位SQLタブで、CPU利用率 (%)**を選択し、降順に並べ替えます。
説明
CPU利用率 (%)は、そのSQLの総CPU時間が全SQLの総CPU時間に占める割合を示しています。CPU利用率が高いほど、消費するCPUリソースが多いことを意味します。
対象SQLを見つけたら、**SQLテキスト**列のリンクをクリックしてSQL詳細ページに移動し、以下の問題が存在するか確認し、適切な対策を講じます：
問題確認方法処理の推奨事項実行計画の悪化 - 対象SQLが疑わしいSQLであるか確認します（詳細は疑わしいSQLを参照してください）。
- 対象SQLの実行計画リストを確認し、SQLの履歴傾向と照らし合わせて計画が変更された時点を分析します。
- 該当SQLのPlan Cacheをリフレッシュします。
- 実行計画を固定します。
- レート制限を行います。
リクエスト量の急増 CPU異常が発生した期間内における対象SQLの**合計実行数**が急増していないか確認します（詳細はTop SQLを参照してください）。 - インデックスを全面的に最適化します。
- レート制限を行います。
パフォーマンスの低下 CPU異常が発生した期間内における対象SQLの**CPU時間**が上昇していないか確認します（詳細はTop SQLを参照してください）。 - 該当SQLのPlan Cacheをリフレッシュします。
- インデックスを全面的に最適化します。
- レート制限を行います。
よくある質問
1. CPU時間はどのように計算されますか？
現在、OBServerにはSQLがCPUリソースを消費する指標がありません。OASは以下の公式を用いてSQL実行過程で消費されたCPU時間を計算します：
v$ob_sql_audit.execute_time + v$ob_sql_audit.get_plan_time - v$ob_sql_audit.total_wait_time_micro
説明
- execute_time：計画の実行時間。
- get_plan_time：実行計画を生成した時間。
- total_wait_time_micro：実行過程での全待機時間の合計。
モニタリング指標の詳細については、SQL Auditをご参照ください。
2. なぜCPU時間でソートし、応答時間(v$ob_sql_audit.elapsed_time)ではないのですか？
以下の図は、OBServerでSQLが実行される際のおおよその時間モデルです。
注意
- OBServerとは異なり、OASは実行計画を取得した時間をCPU時間に加算しています。
- SQLの解析時間は通常短いため、CPU時間には含まれません。
上図からわかるように、SQLは実行前にSQLキューでリソース（通常はアイドルスレッド）を待機します。待機中はCPUリソースをほとんど消費しません。
CPU使用率が高すぎると、SQLキューにSQLが滞留し、SQLの待ち時間が長くなります。その結果、応答時間（v$ob_sql_audit.elapsed_time）ではSQLが消費するCPUリソースを正確に反映できなくなります。
したがって、CPU使用率が高い場合は、主にCPU時間でソートすることを推奨します。