1. はじめに
以前、「Autonomous DBのCPU自動スケーリングを試してみた」1 という記事で、Autonomous Database のコンピュート自動スケーリングを ON にすると CPU が 3倍まで使えるようになることを確かめました。そのとき「セッション数やメモリサイズはベース ECPU 数に紐づくため変化しない」と書いたのですが、これは公式ドキュメントを読んだうえでの記述で、自分で測ったわけではありませんでした。
改めて公式ドキュメントを見ると、Database Service Names2 に次の記述があります。
the sessions parameter is set to 75 times the number of base ECPUs
「ベース ECPU の 75倍」と、ベース ECPU に限定して書かれています。自動スケーリングで増える分は含まれない、と読めます。一方で同じドキュメントには、自動スケーリングの ON / OFF で値が変わる別の上限も載っています。
「セッション数の上限」と一言で呼んでいるものは、1つではありません。2 ECPU / 4 ECPU / 8 ECPU の 3サイズで自動スケーリングを切り替えて、何が変わって何が変わらないのかを確かめました。
1.1. 結論（先出し）
-
sessionsは 75 × ベース ECPU で、自動スケーリングの ON / OFF では変わらない。2 / 4 / 8 ECPU のすべてで 150 / 300 / 600 だった - 自動スケーリング ON で 3倍になった初期化パラメータは
cpu_countとparallel_max_serversとparallel_servers_targetの 3つ。接続の上限とメモリは変わらない -
cpu_countのベース値はベース ECPU の半分。ECPU の数がそのまま見えるわけではない - 「セッション数」に見える上限はもう 1つある。サービス別の同時実行数のほうは、公式の数式上は自動スケーリングで変わる。こちらは今回は実測していない
1.2. 検証ゴール
| # | 確かめること | 確認できれば OK の条件 |
|---|---|---|
| G1 | 接続の上限は自動スケーリングで変わるか | 3サイズ × ON / OFF の 6通りで sessions の値が取れ、ON / OFF で同じかどうかが言える |
| G2 | 3倍になるのは何か | 同じ 6通りで、ON のとき 3倍になるパラメータとならないパラメータが分けられる |
| G3 | ECPU 数はデータベースからどう見えるか |
cpu_count とベース ECPU 数の対応が 3サイズで言える |
2. 検証環境
| 項目 | 値 |
|---|---|
| データベース | OCI Autonomous Database Serverless（Oracle AI Database 26ai） |
| コンピュートモデル | ECPU |
| リージョン | ap-tokyo-1 |
| 接続サービス | HIGH |
| 接続ユーザー |
SELECT_CATALOG_ROLE を持つ一般ユーザー（ADMIN ではない） |
| クライアント | SQLcl 26.1.0.086.1709 / OCI CLI 3.86.0 |
3. 「セッション数」に見える上限は 2種類ある
測り始める前に、公式ドキュメントで用語を整理しておきます。ここを混同すると結果の読み方を間違えます。
3.1. 接続の上限（sessions パラメータ）
データベース全体で同時に確立できるセッションの本数の上限です。ここに達すると新しい接続を確立できません。1 章で引用した Database Service Names によれば、tpurgent / tp / low の 3サービスはこのパラメータで頭打ちになり、値は 75 × ベース ECPU 数です。
3.2. サービス別の同時実行数
こちらは接続の本数ではなく、そのサービスで同時に走らせられる文の数です。Service Concurrency3 に数式の表があり、ECPU モデルでは次のようになっています。
| サービス | 自動スケーリング OFF | 自動スケーリング ON |
|---|---|---|
tpurgent / tp / low
|
75 × ECPU 数 | 75 × ECPU 数（同じ） |
high |
3 | 9 |
medium |
0.25125 × ECPU 数（切り捨て） | 0.75375 × ECPU 数（切り捨て） |
high と medium だけ、自動スケーリング ON で 3倍になります。つまり「自動スケーリングでセッション関連の上限は一切変わらない」と言い切ると、この表の内容と一致しません。
さらに同じページには、小さい構成では別の値になると書かれています。
When the number of ECPUs is 2, all services use the concurrency limit 150.
2 ECPU では全サービスが一律 150、3 ECPU では一律 225 で、自動スケーリングの ON / OFF に関係なく同じ値です。上の表で high と medium が 3倍になるのは 4 ECPU 以上の話で、最小構成の 2 ECPU で試すと一律の値になるため差が出ません。
なお同時実行数を確認する CS_RESOURCE_MANAGER.LIST_CURRENT_RULES()4 は、今回使ったユーザーでは ORA-00904（無効な識別子）になり実行できませんでした。呼び出し方は公式ドキュメントの例と同じ形なので、パッケージが見えていないときに出るエラーだと考えられます。本記事の実測は 3.1 章の接続の上限に絞っています。
4. 確かめかた
ベース ECPU を 2 / 4 / 8 と変えながら、それぞれで自動スケーリングを OFF と ON に切り替えた 6通りの条件で測りました。
| 条件 | ベース ECPU | 自動スケーリング |
|---|---|---|
| 1 | 2 | OFF |
| 2 | 2 | ON |
| 3 | 4 | OFF |
| 4 | 4 | ON |
| 5 | 8 | OFF |
| 6 | 8 | ON |
取得したのは初期化パラメータです。全条件で一字も変えずに同じスクリプトを実行しています。
SELECT name, value, isdefault
FROM v$parameter
WHERE name IN ('sessions',
'processes',
'cpu_count',
'sga_target',
'pga_aggregate_target',
'pga_aggregate_limit',
'parallel_max_servers',
'parallel_servers_target',
'parallel_degree_policy',
'resource_manager_plan')
ORDER BY name;
10個を指定していますが、返ってきたのは 9行でした。processes は Autonomous Database の v$parameter に現れないため、以降の結果からは外れています。
条件の変更は OCI CLI で行い、スケール変更が終わってからデータベースへ接続しました。
oci db autonomous-database update --autonomous-database-id "$ADB_OCID" --compute-count 4 --wait-for-state AVAILABLE
oci db autonomous-database update --autonomous-database-id "$ADB_OCID" --is-auto-scaling-enabled true --wait-for-state AVAILABLE
条件が反映されているかは、取得の直前に毎回 OCI 側から読み直しました。5 章の表のベース ECPU と自動スケーリングは、指定した値ではなくこの実測値です。
oci db autonomous-database get --autonomous-database-id "$ADB_OCID" --query 'data.{state:"lifecycle-state",ecpu:"compute-count",autoscale:"is-auto-scaling-enabled"}'
なお今回読んでいるのは、負荷をかけていない状態での設定値です。実際に 150本の接続を確立して上限に到達するところまでは確かめていません。
5. 実測結果
6通りの条件で取得した値です。メモリ関連は v$parameter がバイトで返すため、MiB に換算しています（1 MiB = 1,048,576 バイト。いずれも割り切れます）。
| ベース ECPU | 自動スケーリング | cpu_count |
sessions |
parallel_max_servers |
sga_target |
pga_aggregate_limit |
|---|---|---|---|---|---|---|
| 2 | OFF | 1 | 150 | 6 | 4,000 MiB | 3,000 MiB |
| 2 | ON | 3 | 150 | 18 | 4,000 MiB | 3,000 MiB |
| 4 | OFF | 2 | 300 | 12 | 8,000 MiB | 6,000 MiB |
| 4 | ON | 6 | 300 | 36 | 8,000 MiB | 6,000 MiB |
| 8 | OFF | 4 | 600 | 24 | 16,000 MiB | 12,000 MiB |
| 8 | ON | 12 | 600 | 72 | 16,000 MiB | 12,000 MiB |
parallel_servers_target は全条件で parallel_max_servers と同じ値でした。pga_aggregate_target は 2 / 4 / 8 ECPU で 1,500 / 3,000 / 6,000 MiB となり、自動スケーリングの ON / OFF では変わりませんでした。
6. 考察
6.1. 3倍になるものと、ならないもの
自動スケーリングを ON にして 3倍になった初期化パラメータは、cpu_count と parallel_max_servers と parallel_servers_target の 3つでした。sessions とメモリ関連のパラメータは、同じベース ECPU なら ON でも OFF でも同じ値です。
| 値の変わり方 | パラメータ |
|---|---|
| 自動スケーリング ON で 3倍 |
cpu_count / parallel_max_servers / parallel_servers_target
|
| ベース ECPU に比例（自動スケーリングでは変わらない） |
sessions / sga_target / pga_aggregate_target / pga_aggregate_limit
|
sessions は 3サイズすべてで 75 × ベース ECPU と一致しました（2 ECPU で 150、4 ECPU で 300、8 ECPU で 600）。ドキュメントの数式どおりで、「ベース」ECPU という但し書きも実測と合っています。
parallel_max_servers と parallel_servers_target が 3倍になる点は、サービス別同時実行数の表には記載がありません。並列問い合わせに割り当てられるプロセス数まで 3倍になるので、自動スケーリングで増えるのは CPU 時間だけではないことになります。
変わる値は初期化パラメータだけではありませんでした。リソースマネージャのプラン・ディレクティブを見ると、OTHER_GROUPS の UTILIZATION_LIMIT が OFF で 100、ON で 33 になっており、3サイズとも同じでした。ベースの 3倍まで使える状態では、どのサービスにも割り当てられない処理が全体の 33% までに制限される、ということになります。ベース ECPU 換算ではおおむね同じ量に収まる設定と考えられますが、この点は今回は測っていません。
6.2. cpu_count はベース ECPU の半分
cpu_count のベース値は 2 ECPU で 1、4 ECPU で 2、8 ECPU で 4 でした。ECPU 数の半分です。自動スケーリング ON ではそれぞれ 3 / 6 / 12 になります。
Oracle LiveLabs の Apply Auto Scaling5 にも、4 ECPU のときは CPU_COUNT が 2 で、自動スケーリングを有効にすると 2 から 6 に上がる、と記載されています。今回の 4 ECPU の値（OFF で 2、ON で 6）と一致しました。
なお Use Auto Scaling6 には、CPU と IO が最大 3倍になるとだけ記載されています。メモリやセッションについての記載はありません。5 章の実測はこの記述と矛盾しません。
ECPU 数と cpu_count が一致しない点は、この対応関係で説明できます。
6.3. 接続プールの最大接続数をどう決めるか
接続の上限がベース ECPU で決まる以上、自動スケーリングを ON にしても同時に確立できる接続の本数は増えません。アプリケーション側の接続プールの最大接続数は、自動スケーリング後の値ではなくベース ECPU から計算した sessions を基準に決めることになります。2 ECPU なら上限は 150 です。
接続プールを使う構成では、負荷とは無関係にこの上限へ近づきます。プールは接続を保持し続けるため、SQL を実行していない間もその本数が上限に数えられます。アプリケーションサーバを 10台並べてそれぞれプールの最大値を 20 にすると、負荷がまったく無くても 200本を要求することになり、2 ECPU の 150 を起動した時点で超えます。しかも超えたときは接続そのものが失敗します。
同時実行数のほうは、実際に文を実行しているセッションだけが対象で、待機中のプール接続は数えません。上限に達しても、失敗ではなく順番待ちになります。
そのためプールのサイジングで先に確認するのは sessions です。台数 × プール最大値の合計を、ベース ECPU から計算した値に収める。同時実行数は、混んだときにどれだけ待たされるかとして別に見ることになります。ECPU を増やせば両方が上がりますが、自動スケーリングで増えるのは同時実行数だけで、sessions は増えません。
6.4. スケーリングの最中にセッションは切れるか
4 章のとおり、今回は ECPU を 2 / 4 / 8 と何度も変えています。その最中に、開いたままの接続がどうなるのかも確かめました。
Compute Models in Autonomous AI Database7 には次の記述があります。
Performing a significant scale-down of ECPUs (such as scaling down ECPUs by 30% or more) may result in dropped connections, disconnected sessions, and a cancellation and rollback of incomplete jobs.
ECPU を 30% 以上縮小したときに、接続断・セッション切断・未完了ジョブのロールバックが起こりうる、と書かれています。拡大については同じ記述が見当たりません。
そこでセッションを 1本開いたまま 1.5 秒ごとに記録を書き続け、その間にスケーリングを掛けました。拡大（2 → 4、4 → 8）、自動スケーリングの ON / OFF 切り替え、閾値未満の縮小（8 → 6、25%）、閾値を超える縮小（6 → 2、67%）の 6通りです。
6通りとも切断されませんでした。 記録の間隔は最大でも 1.51 秒で、3 秒を超える中断は 1度もありません。閾値を超える 67% の縮小でも、未コミットのまま抱えていた行はロールバックされず、そのままコミットできました。
ただしこれを「スケーリングは安全」と読むのは行き過ぎです。公式の書き方は「起こりうる（may result in）」であって、常に起こるとは書かれていません。今回切れなかったことは、この記述と矛盾しません。そして今回の条件は、アイドル状態のデータベースに接続 1本だけ、並行する負荷なしです。容量が小さくなるときにセッションを退避させる必要が生じなかっただけ、とも考えられます。言えるのは、この条件では切れなかった、というところまでです。
7. まとめ
Autonomous Database の自動スケーリングを ON にしたときのセッション数の上限を、2 / 4 / 8 ECPU で確かめました。
-
sessionsは 75 × ベース ECPU。自動スケーリングでは増えない - 3倍になるのは
cpu_countとparallel_max_serversとparallel_servers_target。接続の上限とメモリは変わらない -
cpu_countのベース値はベース ECPU の半分 - 「セッション数の上限」には接続の本数とサービス別の同時実行数の 2種類があり、後者は自動スケーリングで変わる
最後の点には注意が必要です。最小構成の 2 ECPU だけで試すと全サービスが一律の値になり、同時実行数も含めて「自動スケーリングでは何も変わらない」という結論になってしまいます。差が出るのは 4 ECPU 以上です。
参考
-
Autonomous DBのCPU自動スケーリングを試してみた（前回の記事） ↩
-
Database Service Names for Autonomous AI Database（Oracle Cloud Infrastructure ドキュメント。
sessionsはベース ECPU の 75倍） ↩ -
Service Concurrency（サービス別の同時実行数の数式と、2 / 3 ECPU で一律の値になること） ↩
-
Change MEDIUM Service Concurrency Limit (ECPU Compute Model)（
CS_RESOURCE_MANAGERの使い方。4 ECPU 以上が前提） ↩ -
Apply Auto Scaling（Oracle LiveLabs のハンズオン。4 ECPU で
CPU_COUNTが 2、自動スケーリング有効で 6） ↩ -
Use Auto Scaling（自動スケーリングで CPU と IO が最大 3倍） ↩
-
Compute Models in Autonomous AI Database（ECPU の定義と最小値、および 30% 以上の縮小に関する注意書き） ↩