RDSのCPUUtilization・DBLoad・DBLoadCPUの違いを負荷をかけて比べてみた
はじめに
RDSの負荷を表すメトリクスには、CloudWatchの「CPUUtilization」と、Performance Insightsの「DBLoad」「DBLoadCPU」があります。
どれも「負荷」を表すメトリクスですが、何が違うのかがわかりにくかったため、
CPU負荷とロック待ちの2種類の負荷をかけて、実際の値の動きを比較しました。
結論
- CPUUtilizationは100%で頭打ちになる
- DBLoad・DBLoadCPUは同時に動いているセッション数に比例して増え続ける
- CPU負荷ではDBLoad ≒ DBLoadCPUになる
- ロック待ちではDBLoadは高いのに、CPUUtilizationとDBLoadCPUはほぼ0になる
各メトリクスについて
今回比較検証するメトリクスは下記になります。
- CPUUtilization
インスタンス全体のCPU使用率(%)です。全vCPUの平均値のため、1つのクエリが1コアを使い切っていても、vCPU数が多いと低く見えます。上限は100%で、それ以上CPUが不足していても値は増えません。
- DBLoad
ある時点で処理中または待機中のセッション数の平均(AAS:平均アクティブセッション数)です。CPU処理だけでなく、ロック待ちやI/O待ちのセッションも含みます。上限はなく、vCPU数と比べることで、DBが処理を抱えすぎていないかを判断できます。
- DBLoadCPU
DBLoadのうち、CPUを使用中またはCPUの空きを待っているセッション数です。vCPU数を超えていればCPU不足を意味します。DBLoadとの差がCPU以外の待ち(ロック・I/Oなど)の量になります。
| メトリクス | 意味 | 単位 | 取得元 |
|---|---|---|---|
| CPUUtilization | インスタンスのCPU使用率 | % | CloudWatch |
| DBLoad | 処理中・待機中のセッション数の平均 | AAS(平均アクティブセッション数) | Performance Insights |
| DBLoadCPU | DBLoadのうち、CPUを使用中・CPU待ちのセッション数 | AAS | Performance Insights |
検証環境
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1 |
| エンジン | PostgreSQL 16.x |
| インスタンスクラス | db.m6g.large(2 vCPU / 8 GiB) |
| ストレージ | gp3 50 GiB |
| 負荷クライアント | EC2 t3.medium |
| 負荷ツール | pgbench |
- バースト可能インスタンス(db.t系)はCPUクレジットの影響で結果が変わるため、使用していません。
- 今回は負荷をかけるために、PostgreSQL付属のベンチマークツール pgbench を使いました。
pgbenchは、指定したSQLを指定した同時接続数で繰り返し実行できるツールです。
検証シナリオ
各シナリオを5分ずつ実行しました。
シナリオ1〜3では、CPUだけを使うクエリを同時接続数1・2・8で実行しています。同時接続数をvCPU数より少ない・同じ・多いの3段階に変え、CPUUtilizationとDBLoad・DBLoadCPUの増え方の違いを確認します。
シナリオ4では、1セッションが行ロックを保持したまま待機し、20セッションが同じ行を更新しようとして待たされる状況を作りました。CPUを使わない「待ち」が、各メトリクスにどう表れるかを確認します。
| No | シナリオ | 同時接続数 | 内容 |
|---|---|---|---|
| 1 | CPU 並列数1 | 1 | CPUを使うクエリを1セッションで実行 |
| 2 | CPU 並列数2 | 2 | 同じクエリをvCPU数と同じ2セッションで実行 |
| 3 | CPU 並列数8 | 8 | 同じクエリをvCPU数の4倍の8セッションで実行 |
| 4 | ロック待ち | 1 + 20 | 1セッションが行ロックを保持し、20セッションが同じ行を更新 |
シナリオ1〜3:CPU負荷
使用したSQL(cpu.sql)
SELECT count(*) FROM generate_series(1, 3000000) g WHERE md5(g::text) LIKE 'a%';
1〜300万の数値を生成し、それぞれのMD5ハッシュを計算するクエリです。
テーブルを読まないため ディスクI/Oが発生せず、CPUだけを使う のがポイントです。
パラレルクエリの無効化により1セッションが同時に使えるのは1コアだけなので、このクエリを1セッションで流すと「1コアを使い切る」状態になります。
CPUUtilizationが何%になるかは同時接続数によって決まり、2 vCPUの場合は2セッション以上で100%に達します。
export PGOPTIONS='-c max_parallel_workers_per_gather=0'
また、事前設定としてPostgreSQLのパラレルクエリを無効にしています。
パラレルクエリが有効だと、1つのセッションでも複数のワーカープロセスが動いて複数コアを使い、
ワーカーもDBLoadにカウントされます。今回は「同時接続数 = 動いているセッション数」として比較したいため、無効にしました。
実行コマンド
# シナリオ1:並列数1
pgbench -n -c 1 -j 1 -T 300 -f cpu.sql
# シナリオ2:並列数2(vCPU数と同じ)
pgbench -n -c 2 -j 2 -T 300 -f cpu.sql
# シナリオ3:並列数8(vCPU数の4倍)
pgbench -n -c 8 -j 8 -T 300 -f cpu.sql
| オプション | 意味 |
|---|---|
-n |
実行前のVACUUMを行わない(pgbench標準のテーブルを使わないため) |
-c |
同時接続数。シナリオ間で変えたのはこの値だけ |
-j |
pgbench側のスレッド数。クライアント側がボトルネックにならないよう -c と同じ値にした |
-T 300 |
300秒(5分)間、SQLを繰り返し実行する |
-f |
実行するSQLファイル |
シナリオ4:ロック待ち
1つのセッションが行ロックを持ったまま待機し、そこに20セッションが同じ行を更新しにいく状況を作りました。
準備
CREATE TABLE lock_test (id int PRIMARY KEY, v int);
INSERT INTO lock_test VALUES (1, 0);
① ロックを保持するセッション
BEGIN;
UPDATE lock_test SET v = v + 1 WHERE id = 1; -- 行ロックを取得
SELECT pg_sleep(300); -- ロックを持ったまま5分待機
COMMIT; -- ロックを解放
UPDATEで取得した行ロックは、COMMITするまで解放されません。
pg_sleep() で5分間、ロックを持ったまま何もしない状態にしています。
② ロックを待つ20セッション
①を実行した状態で、別のターミナルから実行します。
pgbench -n -c 20 -j 4 -T 290 -f lock.sql
lock.sql:
UPDATE lock_test SET v = v + 1 WHERE id = 1;
20セッションが①と同じ行を更新しようとしますが、①がロックを持っているため全員が待たされます。
実行時間を①より10秒短い290秒にしているのは、ロック解放後に更新が流れ始める状態を計測に含めないためです。
このとき起きていること
①ロック保持: BEGIN → UPDATE(ロック取得) → pg_sleep → COMMIT
↑
②20セッション: UPDATE → 待機
| セッション | 状態 | CPU使用 |
|---|---|---|
| ① 1セッション | pg_sleep() 実行中 |
ほぼなし |
| ② 20セッション | ロック解放待ち | ほぼなし |
どのセッションもCPUを使っていませんが、21セッションすべてが「実行中」のまま止まっています。
検証結果
シナリオ1: CPU 並列数1, CPUUtilizationは50%
CPUUtilizationが50%、DBLoad/DBLoadCPUが1になっています。
今回はパラレルクエリを無効化しており、PostgreSQLは1セッションを1プロセスで処理するため、
このクエリは1コアしか使えません。
2 vCPUのうち1コアがフル稼働しているので、平均すると約50%になります。
CPUUtilizationが50%でも、クエリ自体は1コアを使い切っています。
vCPU数が多いインスタンスほど、この「薄まり」は大きくなります(4 vCPUなら約25%、16 vCPUなら約6%)。
シナリオ2: CPU 並列数2, すべてのvCPUが埋まる
CPUUtilizationが100%、DBLoad/DBLoadCPUが2になっています。
2つのセッションがそれぞれ1コアずつ使い、全コアがちょうど埋まった状態です。
シナリオ3: CPU 並列数8, CPUUtilizationは変わらず、DBLoadだけ増える
CPUUtilizationが100%、DBLoad/DBLoadCPUが8になっています。
CPUUtilizationはシナリオ2と見分けがつきませんが、DBLoadは4倍になりました。
2つのvCPUを8セッションで奪い合い、常に約6セッションがCPUの空きを待っている状態です。
CPUUtilizationだけでは、この「待ち」に気づけません。
シナリオ4: ロック待ち, DBLoadだけが高い
CPUUtilizationが4%、DBLoadが21、DBLoadCPUが0になりました。
DBLoadは全シナリオで最も高くなりましたが、CPUUtilizationとDBLoadCPUはほぼ0でした。
セッションはロックの解放を待っているだけで、CPUを使っていないためです。
DBLoadが20ではなく約21になったのは、待機中の20セッションに加えて、
ロックを保持しているセッションも pg_sleep() を実行中(アクティブ)としてカウントされるためです。
DBLoadだけを見るとシナリオ3以上に「CPU不足」に見えますが、
この状態でインスタンスサイズを上げても改善しません。
1〜4のシナリオ結果を表でまとめると下記になります。
| メトリクス | 1. CPU×1 | 2. CPU×2 | 3. CPU×8 | 4. ロック待ち |
|---|---|---|---|---|
| 同時接続数 | 1 | 2 | 8 | 1 + 20 |
| CPUUtilization | 約50% | 約100% | 約100% | 数% |
| DBLoad | 約1 | 約2 | 約8 | 約21 |
| DBLoadCPU | 約1 | 約2 | 約8 | 約0 |
| DBLoad − DBLoadCPU(CPU以外の待ち) | 約0 | 約0 | 約0 | 約21 |
まとめ
シナリオ1〜3ではDBLoadとDBLoadCPUがほぼ一致し、シナリオ4では大きく離れました。
DBLoadとDBLoadCPUの差を見れば、混雑の原因がCPUかどうかを判断できます。
CPUUtilizationは「CPUがどれだけ使われているか」、DBLoadは「DBがどれだけ処理を抱えているか」を表します。
CPUUtilizationだけでは、CPU待ちの深刻さやCPU以外の待ちに気づけないため、
DBLoad・DBLoadCPUと組み合わせて監視するのがおすすめです。
| 知りたいこと | 見るメトリクス |
|---|---|
| CPUがどれだけ使われているか | CPUUtilization |
| DBがどれだけ混雑しているか | DBLoad(vCPU数と比べる) |
| 混雑の原因がCPUかどうか | DBLoadCPU(DBLoadと比べる) |
| 状態 | 判断 |
|---|---|
| DBLoad ≒ DBLoadCPU > vCPU数 | CPU不足 → スケールアップやクエリのチューニング |
| DBLoad > vCPU数 だが DBLoadCPU は低い | CPU以外の待ち → Performance Insightsで待機イベントを確認 |
| CPUUtilizationは低いが、DBLoadCPUが小さい値で張り付いている | 少数のクエリが1コアを使い切っている → クエリのチューニング |
注意点
- CloudWatchのDBLoad系メトリクスは1分粒度です。細かい推移はPerformance Insightsで確認できます
- バースト可能インスタンス(db.t系)では、CPUクレジットの影響を受けます
- パラレルクエリが動くと、1セッションでも複数コアを使い、ワーカーもDBLoadにカウントされます
- CPUUtilizationには、DB以外のプロセスによる使用分も含まれます
参考資料
- Amazon RDS ユーザーガイド:データベース負荷
- Amazon RDS ユーザーガイド:CloudWatch に発行される Performance Insights メトリクス
- Amazon RDS ユーザーガイド:Amazon RDS の Amazon CloudWatch メトリクス
- PostgreSQL 16 ドキュメント:pgbench
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
（※2026年1月、アノテーション株式会社から社名変更しました。）
