AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post

Amazon RDS for Oracle データベースの CPU 使用率が高い場合のトラブルシューティング方法を教えてください。

所要時間4分
0

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

簡単な説明

Oracle 用 RDS データベースの CPU 使用率が高い場合は、次のツールを組み合わせて原因を特定してください。

  • Amazon CloudWatch メトリックス
  • モニタリングメトリックスの強化
  • パフォーマンスインサイトメトリックス
  • Oracle Statspack
  • 自動ワークロードリポジトリ (AWR)
  • 自動データベース診断モニター (ADDM)
  • アクティブセッション履歴 (ASH)
  • Oracle SQLT

解決策

CPU 使用率の高さに関連する問題を診断する際には、問題が発生した期間を特定してください。

CloudWatch メトリックス

Amazon RDS は、各アクティブデータベースごとに 1 分に一度メトリックスを CloudWatch に送信します。次の Amazon RDS 用 CloudWatch メトリックスを確認して、長期間にわたる CPU パターンを特定してください。

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

また、次のメトリックスを確認して、ワークロードに変化があったり、しきい値を超えていなかったりしていないかどうかを確認してください。これらの要因が CPU 使用率の急上昇の一因となっている可能性があります。

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

詳細については、「Amazon CloudWatch による Amazon RDS メトリクスのモニタリング」および「インスタンスのステータスと推奨事項の表示」を参照してください。

モニタリングメトリックスの強化

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

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

CPU 使用率が急上昇した期間を確認するには、以下を実行してください。

  1. Amazon RDS コンソールを開きます。
  2. ナビゲーションペインで [データベース] を選択します。
  3. 監視するデータベースを選択します。
  4. [モニタリング] タブを選択します。
  5. [モニタリング] ドロップダウンリストから [拡張モニタリング] を選択します。
  6. [拡張モニタリング] ビューで、インスタンスがマルチ AZ 配置の場合は、[プライマリ] を選択すると、プライマリインスタンスの OS メトリックが表示されます。[セカンダリ] を選択すると、スタンバイレプリカのメトリックが表示されます。
  7. 日付と開始時間を選択します。
  8. 右隅で期間を選択します。5 分、15 分、30 分、または 1 時間を選択できます。

CPU 合計グラフは、CPU 使用率が増加した期間を示します。

負荷平均 1 分、負荷平均 5 分、負荷平均 15 分のグラフには、それぞれ、直近 1 分、過去 5 分間、過去 15 分間に CPU 時間を要求したプロセスの数が表示されます。負荷平均が vCPU の数よりも大きい場合、インスタンスで CPU のボトルネックが発生している可能性があります。

OS プロセスを表示するには、[モニタリング] ドロップダウンリストから [OS プロセスリスト] を選択します。次に、リストを CPU% 値でソートして、CPU 使用率が最も高いプロセスを特定します。

例:

NAMEVIRTRESCPU%MEM%VMLIMIT
OracleORCL\ [27074]6.07 GiB1,007.24 MB44.7212.78無制限
OracleORCL\ [27076]6.07 GiB1,010.02 MB44.6412.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. ナビゲーションペインで [データベース] を選択します。
  3. 監視するデータベースを選択します。
  4. [モニタリング] タブを選択します。
  5. [モニタリング] ドロップダウンリストから [拡張モニタリング] を選択します。
  6. [拡張モニタリング] ビューで、[グラフの管理] を選択します。
  7. 表示するグラフを選択します。
  8. [保存] を選択します。

表示できるグラフの例:

メモリー

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

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

スワップ

  • スワップ
  • フリー

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

  • 読み取りIO/秒
  • 書き込み IO/秒
  • アベニューキューサイズ
  • 待機中

CPU

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

使用可能なメトリックのリストについては、「拡張モニタリングの概要」を参照ください。

拡張モニタリングの詳細については、「拡張モニタリングによる OS メトリックのモニタリング」を参照してください。

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

パフォーマンスインサイトメトリックス

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

  1. Amazon RDS コンソールを開きます。
  2. ナビゲーションペインで、[パフォーマンスインサイト] を選択します。
  3. 監視する DB インスタンスを選択します。
  4. [過去を表示] にて、お好みの期間を選択します。
  5. データベース負荷グラフで、CPU 使用率が急上昇した時間を確認します。
  6. [上位の待機] タブを選択します。
    スパイク期間中の待機イベントの上位数に注目してください。
  7. [上位の SQL] タブを選択します。
    スパイクの原因となった SQL ステートメントを確認して最適化してください。

パフォーマンスインサイトのコストについては、「パフォーマンスインサイトの価格」を参照してください。

Oracle Statspack

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

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

  1. 問題が発生した期間の統計パックレポートを生成します。
  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 Statspackの Oracle ドキュメントを参照してください。

AWR

AWR (Oracle のウェブサイト上) は、特定の期間のパフォーマンス指標を提供する Oracle のパフォーマンス・レポート・ツールです。

**注:**AWRには診断パックライセンスが必要で、Oracle のエンタープライズエディションでのみ使用できます。

AWR を使用して CPU 負荷の原因を特定するには、以下を実行してください。

1.    次のようなクエリを実行して、CPU 負荷が高い期間の開始スナップショット ID と終了スナップショット 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」セクションにリストされているクエリを確認して最適化してください。

5.    上位の待機イベントを確認してください。

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

注: 4 つ以上の連続したスナップショット ID の AWR レポートが生成された場合、すべての ADDM レポートと ASH レポートは含まれません。これらの追加レポートを生成するには、以下のセクションの指示に従ってください。

ADDM

ADDMは、AWRデータを分析し、パフォーマンスのボトルネックを特定し、推奨事項を提供する診断ツールです。

**注:**ADDMには診断パックのライセンスが必要で、Oracle のエンタープライズエディションでのみ使用できます。

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

SELECT SNAP_ID, BEGIN_INTERVAL_TIME FROM DBA_HIST_SNAPSHOT ORDER BY 1;

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

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

4.    ADDM レポートの推奨事項を確認してください。

ASH

ASH (オラクルウェブサイト) は、アクティブなセッション情報を収集する診断ツールです。ASH を使用して一時的なパフォーマンスの問題をトラブルシューティングするには、以下を実行してください。

**注:**ASH には診断パックのライセンスが必要で、Oracle のエンタープライズエディションでのみ使用できます。

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

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

3.    「TOP SQL と TOP Events」のセクションを確認してください。

AWR、ADDM、およびASHレポートの解釈については、Oracle Support Doc ID FAQに関する Oracle サポートドキュメントを参照してください。 自動ワークロードリポジトリ (AWR) レポート (ドキュメントID 1599440.1)。

Oracle SQLT

Amazon RDS は SQLT オプションを使用して Oracle SQLTXPLAN (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’);

関連情報

Amazon RDS のモニタリングメトリクスの概要

自動ワークロードリポジトリ (AWR) によるパフォーマンスレポートの生成

ADDM レポートの生成

ASH レポートの生成

Oracle を実行している Amazon RDS DB インスタンスのパフォーマンス統計を確認する方法を教えてください。

トピック
移行と近代化分析データベース
タグ
Amazon Relational Database ServiceOracle
言語
日本語

関連ビデオ

詳細については、Utsav のビデオをご覧ください (10:14)
詳細については、Utsav のビデオをご覧ください (10:14)
AWS公式
AWS公式更新しました 3年前
コメントはありません

関連するコンテンツ