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

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

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

CPUスレッド数制限について

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

SE2での制限
・搭載可能CPUソケット数は2つまで（全OSで共通）
・インスタンスあたり最大16CPUスレッドまでしか同時に使用できない

この「インスタンスあたり最大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スレッドを占有する処理を実行します。このセッションを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"の待機イベントで待機していました。

16セッション時のmpstatでは16スレッドが100%

20セッション時のmpstatではCPU使用率が抑えられている

16セッション時のv$session

20セッション時のv$session

resmgr:cpu quantumとは

セッションは、CPU数を割り当てるために待機しています。このイベントは、リソース・マネージャが使用可能で、CPU消費量を抑えている場合に発生します。この待機イベントの発生を減らすには、セッションのカレント・コンシューマ・グループに割り当てるCPUを増やします。

Oracle® Databaseリファレンス 12cリリース1 (12.1)より抜粋

検証結果

Resource Managerがスレッドを制御

「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スレッドを占有できていることから、バックグラウンドプロセスについてはスレッド数制限の適用外のようです。

v$session抜粋

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

まとめ

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


どうやって制御しているのか	Resource Managerで制御している
16セッションまでしか同時に接続できないのではないか	17以上のセッションでも接続可能だが、同時に使用するCPUスレッドが16CPUスレッドで収まるようにResource Managerで待機させながら処理が行われる
バックグラウンドプロセスも影響を受けるのか	異なるコンシューマグループに所属しておりCPUスレッド数制限を受けない
同一サーバ内で複数データベースを構築している場合はどのように制御されるのか	？？？（～その2～で紹介予定）
SE2 RACではどのように制御されるのか	？？？（～その3～で紹介予定）

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

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

検証メンバー

データベース技術本部：田中勝之、嚴ミン智、黒田洸平、小山雄貴

筆者情報

大野高志

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

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

■本記事の内容について
　本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
　・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
　・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
　　文中の社名、商品名等は各社の商標または登録商標である場合があります。