【Oracle Database 12c】Oracleライセンス「SE2」検証　CPUスレッド数制限はどんな仕組みで制御されるのか：データベースサポート最前線の現場から（12）（2/2 ページ）

検証結果：「Resource Manager」がスレッドを制御している

　これらの検証から「インスタンス当たり、最大で16CPUスレッドまでしか同時に使えない」ようにする制限は、「Resource Manager」が掛けていることが分かりました。Resource ManagerはこれまでのSEで利用可能だった機能ですが、内部的な制御のためにSE2でも使われているようです。

　20セッション時（画像2の右）は、SE2の制限を超える17スレッド以上を使用しているわけですが、内部の動きとしては、16スレッドを超えるとそれ以降は処理を行わなくなるのではなく、「同時に使用するスレッドが16まで」になるように「resmgr:cpu quantum」で待機させながら調節しているのです。ちなみに、Resource Managerはスレッド数の上限に達してから動作するため、15セッションまではresmgr:cpu quantumの待機イベントは発生しませんでした。

　続いてバックグラウンドプロセスはどうでしょう。Resource Managerによる制御であることを踏まえて、バックグラウンドプロセスの「V$SESSION.RESOURCE_CONSUMER_GROUP」を確認してみます（画像3）。

画像3　「V$SESSION.RESOURCE_CONSUMER_GROUP」を確認（v$sessionを抜粋）

　一般ユーザーのセッションは「OTHER_GROUPS」ですが、バックグラウンドプロセスは「_ORACLE_BACKGROUND_GROUP_」という、異なるグループに所属していました。これまでの検証結果で「ユーザーセッションのみ」で16スレッドを占有できていることから、バックグラウンドプロセスにおいては「スレッド数制限の適用外」となるようです。

　ちなみに、初期化パラメータ「RESOURCE_MANAGER_PLAN」などの変更でこの制限を無効にできないかを試してみましたが、もちろんダメでした（当たり前ですが）。

　ちなみに「resmgr: cpu quantum」は、従来のSE、SE1でも自動オプティマイザ統計収集の時などに出るケースはありましたが、ともあれ「V$SESSION」や「STATSPACK」などを使ってパフォーマンス監視をしている人は、Oracle Database 12c SE2の移行後に「resmgr: cpu quantum」の待機イベントを発見してドキッとしてしまわないように、Resource Managerで制御されることを前もって認識しておく必要がありそうです。

　次回はその他の疑問となる「同一サーバ内で複数のデータベースを構築している場合はどのように制御されるのか」についてを検証します。