Database Support Blog

Database Support Blog>【Oracle SE2】CPUスレッド数制限の動作検証結果~その1~

  • Oracle Database
2016.02.23

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

【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%

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

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

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

16セッション時のv$session

16セッション時のv$session

20セッション時の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抜粋

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 Database
2016.12.09

【Oracle Database】2016年にサポートにお問い合わせをいただいたORAエラー TOP5

2016年にアシストのサポートセンターにお問い合わせいただいたORAエラーのTOP5をご紹介します。

  • Oracle Database
2016.11.16

【Oracle Database】パフォーマンスダウンの原因追求に必要な情報取得サンプルスクリプト

パフォーマンスダウンやCPU/メモリ負荷高騰時には、セッション/プロセス単位で情報を確認する必要があります。原因追求に必要な情報を取得できるサンプルスクリプトを提供します。

  • Oracle Database
2016.10.27

【Oracle Database】うるう秒の対応

Oracle Databaseでのうるう秒(閏秒)の対応方法について解説します。2017年元旦にトラブルとならないよう、準備しましょう。

アシストサポートセンターのご紹介 Oracle Database研修

ページの先頭へ戻る