【Oracle SE2】CPUスレッド数制限の動作検証結果～その１～

Oracle Database SE2のCPUスレッド数制限について、内部的にどのような仕組みで制御しているかを検証しましたので、その結果をご報告します。

昨年に「 SE1/SEからSE2の移行で注意すべきこと 」という記事を書かせていただき、その際、従来のSE/SE1にはなかったCPUスレッド数の制限が追加されたことを紹介しました。

この「インスタンスあたり最大16CPUスレッドまでしか同時に使用できない」という制限について、疑問を持たれたお客様からサポートセンターに下記のようなお問い合わせをいただきました。

・どうやって制御しているのか
・16セッションまでしか同時に接続できないのではないか
・バックグラウンドプロセスも影響を受けるのか
・同一サーバ内で複数データベースを構築している場合はどのように制御されるのか
・SE2 RACではどのように制御されるのか

これらの疑問に答えるべく社内検証チームが確認してくれたので、今回はその資料を拝借してSE2のCPUスレッド（以降、スレッド）数制限の解説をしたいと思います。

今回の検証にあたり、次の環境を使用しています。Hyper-Threadingを有効にして32スレッドあるため、実際にどのように制御されるかを確認できます。

・HP ProLiant DL380e G8 8SFF SAS RDIMM モデル
・Intel Xeon E5-2470 2.30GHz 2P/16C(Hyper-Threading有効)
・128GB メモリ
・HP 600GB 10krpm SC 2.5型 6G SAS HDD*5
・Red Hat Enterprise Linux 6.6
・Oracle Database 12.1.0.2 Standard Edition 2（シングルインスタンス）

下記のような1スレッドを占有する処理を実行します。このセッションを1つずつ増やしていき、制限内の16セッション目、制限を超えた17セッション以降でどのようになるか確認します。

declare
     foo number;
 begin
     while (1=1) LOOP
     foo := 1+1;
     end loop;
 end;
 /
 

セッションを増やしていくと16セッションまではCPUをフルに使用していますが、制限を超えて以降はCPU使用率が抑えられており、何かしらの制限が働いていることがわかります。このセッションがどのような状態になっているのかV$SESSIONで確認すると"resmgr: cpu quantum"の待機イベントで待機していました。

「16CPUスレッドまでしか同時に使用できない」の正体はResource Managerによるものでした。Resource Manager自体はEnterprise Editionで利用可能な機能ですが、内部的な制御のためにStandard Edition 2でも使用されているようです。

20セッションの時には17スレッド以上を使用していることから、決まった16スレッドしか使用できないのではなく、同時に使用するスレッドが16になるように"resmgr:cpu quantum"で待機させながら調節されていることがわかります。また、図にはありませんがResource Managerが動作するのはスレッド制限に達した場合のため、15セッションまでは"resmgr:cpu quantum"の待機イベントは発生しませんでした。

Resource Managerによる制御ということでV$SESSION.RESOURCE_CONSUMER_GROUPを確認したところ、一般ユーザのセッションはOTHER_GROUPSですが、バックグラウンドプロセスは_ORACLE_BACKGROUND_GROUP_という異なるグループに所属していました。今までの検証結果でユーザセッションのみで16スレッドを占有できていることから、バックグラウンドプロセスについてはスレッド数制限の適用外のようです。

ちなみに、初期化パラメータRESOURCE_MANAGER_PLANなどの変更でこの制限を無効化できてしまわないか確認をしてみましたが、勿論ダメでした（当たり前ですが）。

最初に記載した疑問の答えは次のとおりであることがわかりました。現在12.1.0.1以前のSE/SE1環境を利用していて移行を検討している場合には、ピーク時のCPU使用状況とこの仕様を意識した上でライセンスを検討する必要があります。

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

気になる同一サーバ内に複数データベースを作成しているケースや、SE2 RACのスレッド数制限については次回以降に紹介します。

筆者情報

• 大野 高志

サービス事業部　サポートセンター

2007年にアシスト入社後、Oracle Databaseのサポート業務に従事。現在はサポートの傍ら、未解決のトラブルを一つでも多く減らせるよう、サポートセンターに蓄積されているノウハウを社内外に伝える活動を行っている。