Amazon RDS for Oracle Database の高い CPU 使用率をトラブルシューティングするにはどうすればよいですか?

最終更新日: 2021 年 10 月 29 日

Amazon Relational Database Service (Amazon RDS) for Oracle DB インスタンスの CPU 使用率が高くなっています。

簡単な説明

RDS for Oracle Database の CPU 使用率が高い場合は、次のツールを組み合わせて使用して、原因を特定します。

  • Amazon CloudWatch メトリクス
  • 拡張モニタリングメトリクス
  • Performance Insights メトリクス
  • Oracle Statspack
  • 自動ワークロードリポジトリ (AWR)
  • 自動データベース診断モニター (ADDM)
  • アクティブセッション履歴 (ASH)
  • Oracle SQLT

解決方法

高い CPU 使用率に関連する問題を診断するときは、問題が発生した期間を特定します。

CloudWatch メトリクス

Amazon RDS は、アクティブな各データベースについて 1 分ごとにメトリクスを CloudWatch に送信します。次の Amazon RDS の CloudWatch メトリクスを確認して、ある程度の長さの期間で見られる CPU パターンを特定します。

  • CPUUtilization
  • CPUCreditUsage (T2 または T3 インスタンスを使用している場合)
  • CPUCreditBalance (T2 または T3 インスタンスを使用している場合)

また、次のメトリクスを確認して、ワークロードにおける変化の有無、およびしきい値の超過の有無を確認します。これらの要因は、CPU 使用率のスパイクに寄与する可能性があります。

  • DatabaseConnections
  • DiskQueueDepth
  • FreeableMemory
  • ReadIOPS
  • ReadLatency
  • WriteIOPS
  • WriteLatency

詳細については、Amazon RDS のメトリクスおよび DB インスタンスのメトリクスの表示を参照してください。

拡張モニタリングメトリクス

拡張モニタリングにより、DB インスタンスが実行されているオペレーティングシステムのメトリクスがリアルタイムで提供されます。CloudWatch はハイパーバイザーから CPU 使用率メトリクスを取得しますが、拡張モニタリングは DB インスタンスのエージェントからこれらのメトリクスを取得します。拡張モニタリングのメトリクスは、CloudWatch メトリクスよりも詳細です。拡張モニタリングメトリクスは CloudWatch Logs で 30 日間保存されます。

メトリクスの収集間隔は、1 秒から 1 分までの時間で定義できます。ビジネスクリティカルなアプリケーションについては、粒度を 1 秒または 5 秒に設定するのがベストプラクティスです。この粒度にすることで、メトリクスは、パフォーマンスの問題の分析のために、アプリケーションの負荷に関するより正確な情報を提供します。

CPU 使用率のスパイクの期間を表示するには、次の手順を実行します。
  1. Amazon RDS コンソールを開きます。
  2. ナビゲーションペインで、[Databases] (データベース) を選択します。
  3. モニタリングするデータベースを選択します。
  4. [Monitoring] (モニタリング) タブを選択します。
  5. [Monitoring] (モニタリング) ドロップダウンリストから [Enhanced monitoring] (拡張モニタリング) を選択します。
  6. [Enhanced Monitoring] (拡張モニタリング) ビューで、インスタンスがマルチ AZ 配置の場合は、[primary] (プライマリ) を選択してプライマリインスタンスの OS メトリクスを表示します。[secondary] (セカンダリ) を選択して、スタンバイレプリカのメトリクスを表示します。
  7. 日付と開始時刻を選択します。
  8. 右隅で、期間を選択します。[5 minutes] (5 分)、[15 minutes] (15 分)、[30 minutes] (30 分)、または [1 hour] (1 時間) を選択できます。

[CPU Total] (CPU の合計) グラフは、CPU 使用率が増加した期間を示します。

[Load Avg 1 min] (負荷平均 1 分)、[Load Avg 5 min] (負荷平均 5 分)、および [Load Avg 15 min] (負荷平均 15 分) といったグラフには、過去 1 分間、過去 5 分間、過去 15 分間にそれぞれ CPU 時間をリクエストしたプロセスの数が表示されます。負荷平均が vCPU の数より大きい場合、インスタンスで CPU ボトルネックが発生している可能性があります。

OS プロセスを表示するには、[Monitoring] (モニタリング) ドロップダウンリストから [OS process list] (OS プロセスリスト) を選択します。その後、CPU% 値でリストを並べ替えて、CPU 使用率が最も高いプロセスを特定します。

例:

NAME VIRT RES CPU% MEM% VMLIMIT
oracleORCL [27074]ᵗ 6.07 GiB 1,007.24 MB 44.72 12.78 無制限
oracleORCL [27076]ᵗ 6.07 GiB 1,010.02 MB 44.64 12.82 無制限

前述の例の列の詳細については、RDS コンソールでの OS メトリクスの表示を参照してください。

CPU 使用率が最も高いプロセスを特定したら、次のクエリを実行して、プロセス ID をデータベース上のセッションにマッピングできます。

SET LINESIZE 120;
SET PAGES 200;
COL OSUSER FOR a20;
COL USERNAME FOR a20;
COL MACHINE FOR a20;
SELECT a.sid, a.serial#, a.osuser, a.username, a.machine, a.sql_id, c.sql_text FROM v$session a, v$process b, v$sql c 
WHERE a.paddr=b.addr AND b.spid=&spid AND a.sql_id=c.sql_id(+);

デフォルトでは、すべての拡張モニタリングのグラフは、拡張モニタリングダッシュボードに表示されません。CPU 使用率のスパイク時のワークロードを表示するには、次の手順を実行して追加のグラフをオンにします。

  1. Amazon RDS コンソールを開きます。
  2. ナビゲーションペインで、[Databases] (データベース) を選択します。
  3. モニタリングするデータベースを選択します。
  4. [Monitoring] (モニタリング) タブを選択します。
  5. [Monitoring] (モニタリング) ドロップダウンリストから [Enhanced monitoring] (拡張モニタリング) を選択します。
  6. [Enhanced Monitoring] (拡張モニタリング) ビューで、[Manage graphs] (グラフを管理) を選択します。
  7. 表示するグラフを選択します。
  8. [Save] (保存) を選択します。

表示できるグラフの例:

メモリ

  • 無料
  • キャッシュ済み
  • バッファリング済み
  • 合計
  • ダーティ
  • アクティブ
  • スラブ

注: メトリクスに関連するメトリクスは、/proc/meminfo ファイルから取得されます。

スワップ

  • スワップ
  • 無料

ディスク I/O と物理デバイス I/O

  • 読み取り IO/秒
  • 書き込み IO/秒
  • 平均キューサイズ
  • 待機

CPU

  • ユーザー
  • 合計
  • システム
  • 待機
  • アイドル
  • Nice

使用可能なメトリクスのリストについては、MariaDB、MySQL、Oracle、PostgreSQL の DB インスタンスのメトリクスを参照してください。

拡張モニタリングの詳細については、拡張モニタリングを使用した OS のモニタリングを参照してください。

拡張モニタリングのコストについては、拡張モニタリングのコストを参照してください。

Performance Insights メトリクス

Amazon RDS Performance Insights ダッシュボードを使用すると、データベースの負荷を視覚化し、待機、SQL ステートメント、ホスト、またはユーザーによって負荷をフィルタリングできます。

  1. Amazon RDS コンソールを開きます。
  2. ナビゲーションペインで、[Performance Insights] を選択します。
  3. モニタリングする DB インスタンスを選択します。
  4. [View past] (過去の情報を表示) で、任意の期間を選択します。
  5. [Database Load] (データベースの負荷) グラフで、CPU 使用率のスパイクが発生した時刻を確認します。
  6. [Top waits] (上位の待機) タブを選択します。
    スパイクの期間中における上位の待機イベントに注目してください。
  7. [Top SQL] (上位の SQL) タブを選択します。
    スパイクに寄与した SQL ステートメントを確認し、最適化します。

Performance Insights のコストについては、Performance Insights の料金をご覧ください。

Oracle Statspack

Statspack は、特定の期間におけるデータベースのパフォーマンスメトリクスを提供するパフォーマンスレポートツールです。

Statspack を使用してインスタンスの CPU 使用率を確認するには、次の手順を実行します。

  1. 問題が発生した期間の statspack レポートを生成します。
  2. 高い CPU 負荷を生じさせるクエリを確認し、最適化します。
  3. 上位の待機イベントを確認します。

Statspack レポートからの抽出の例:

-> Total DB CPU (s):           3,345
-> Captured SQL accounts for   91.3% of Total DB CPU
-> SQL reported below exceeded  1.0% of Total DB CPU
    CPU                  CPU per            Elapsed                     Old
  Time (s)   Executions  Exec (s)  %Total   Time (s)    Buffer Gets  Hash Value
---------- ------------ ---------- ------ ---------- --------------- ----------
   3043.36      598,100       0.01   91.0    3356.81     994,096,212  219593194

Module: JDBC Thin Client
SELECT tt.ORDER_TOTAL, tt.SALES_REP_ID, tt.ORDER_DATE, customers.CUST_FIRST_NAME, customers.CUST_LAST_NAME FROM   
(SELECT orders.ORDER_TOTAL, orders.SALES_REP_ID, orders.ORDER_DATE, orders.customer_id, rank() Over (ORDER BY orders.O

詳細については、Oracle のドキュメントの Oracle Statspack を参照してください。

AWR

AWR は Oracle のパフォーマンスレポートツールで、特定の期間のパフォーマンスメトリクスを提供します。

注: AWR には Diagnostic Pack ライセンスが必要で、Oracle の Enterprise Edition でのみ使用できます。

AWR を使用して CPU 負荷の原因を特定するには、次の手順を実行します。

1.    次のようなクエリを実行して、CPU 負荷が高い期間の開始および終了のスナップショット ID を特定します。

SELECT SNAP_ID, BEGIN_INTERVAL_TIME FROM DBA_HIST_SNAPSHOT ORDER BY 1;

2.    AWR レポートを生成します。

3.    AWR レポートをダウンロードします。

4.    AWR レポートの [SQL ordered by CPU Time] (SQL (CPU 時間順)) セクションにリストされているクエリを確認し、最適化します。

5.    上位の待機イベントを確認します。

Oracle 12c 以降のバージョンでは、AWR レポートに ADDM および ASH レポートが含まれます。

注: 5 つ以上の連続したスナップショット ID についての AWR レポートが生成される場合、すべての ADDM および ASH レポートは含まれません。これらの追加レポートを生成するには、次のセクションの手順を実行します。

ADDM

ADDM は、AWR データを分析し、パフォーマンスのボトルネックを特定し、レコメンデーションを提供する診断ツールです。

注: ADDM には Diagnostic Pack ライセンスが必要で、Oracle の Enterprise Edition でのみ使用できます。

1.    次のようなクエリを実行して、CPU 負荷が高い期間の開始および終了のスナップショット ID を特定します。

SELECT SNAP_ID, BEGIN_INTERVAL_TIME FROM DBA_HIST_SNAPSHOT ORDER BY 1;

2.    ADDM レポートを生成します。

3.    ADDM レポートをダウンロードします。

4.    ADDM レポートでレコメンデーションを確認します。

ASH

ASH は、アクティブなセッションに関する情報を収集する診断ツールです。ASH を使用して一時的なパフォーマンスの問題をトラブルシューティングするには、次の手順を実行します。

注: ASH には Diagnostic Pack ライセンスが必要で、Oracle の Enterprise Edition でのみ使用できます。

1.    CPU 負荷が高かった期間の ASH レポートを生成します。

2.    ASH レポートをダウンロードします。

3.    [TOP SQL with TOP Events] (上位のイベントがある上位の SQL) セクションを確認します。

AWR、ADDM、および ASH レポートの解釈の詳細については、Oracle Support Doc ID FAQ: Automatic Workload Repository (AWR) Reports (Doc ID 1599440.1) を参照してください。

Oracle SQLT

Amazon RDS は、SQLT オプションの使用を通じて Oracle SQLTXPLAIN (SQLT) をサポートしています。SQLT は、正常に機能しない SQL ステートメントを診断するために使用されるツールです。

特定の SQL ステートメントのレポートを作成するには、Oracle SQLT を参照してください。

SQLT の使用時に次のエラーが表示される場合:

Error: ORA-20106: SQLT parameter connect_identifier must be set when running SQLT from a remote client.

抽出を実行する前に、次のいずれかのコマンドを実行します。

EXEC sqltxadmin.sqlt$a.set_sess_param(‘connect_identifier’, ‘@SID’);
EXEC sqltxadmin.sqlt$a.set_param(‘connect_identifier’, ‘@example-hostname:example-port/example-sid’);