Database Support Blog

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

  • Oracle Database
2016.04.05

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

CPUスレッド数制限の動作検証結果:同一サーバ内でに複数のデータベースが存在する場合

【Oracle SE2】CPUスレッド数制限の動作検証結果~その1~ より、SE2のCPUスレッド数制限はResource Managerで制御されることがわかりました。今回は同一サーバ内で複数のデータベースが存在する場合に、CPUスレッドがどのように制御されるか検証しましたので、その結果を紹介します。

CPUスレッド数制限はデータベース単位で制御される

Oracle JapanのFAQ" Oracle Database Standard Edition 2で制限される「CPUスレッド」とは何ですか? "には、スレッド数制限はデータベース単位で行われ、各データベースごとに使用するCPUスレッドが16(RACの場合は8)までに制限されると記載されています。

"各データベースごとに制限される"という点について「1つのデータベースで制限を超えても、本当に他のデータベースのセッションには影響がないのか」というお問い合わせをいただきましたので、検証結果を紹介します。

検証環境は動作検証結果~その1~と同じ、ハイパースレッドを有効にした32CPUスレッドあるサーバを使用します。データベースを3つ構築して以下2パターンで検証しています。

【検証 1】全てのデータベースで制限内
CPUを使用する処理を行うセッションを12:12:12で実行

【検証 2】1つのデータベースだけ制限超え
CPUを使用する処理を行うセッションを24:12:12で実行

【検証 1】全てのデータベースで制限内
CPUを使用する処理を行うセッションを12:12:12で実行

3つのデータベースでそれぞれ12セッションずつCPUを使用する処理を実行します。各データベースで16CPUスレッドの制限内のためResource Managerで制御されないことが期待される動作です。しかし、サーバに搭載しているCPUスレッド数を超えているためどのように動作するのかがポイントです。

早速、各データベースで12セッションずつCPUを使用する処理を行います。

[DB1]12セッション時のV$SESSION

▲[DB1]12セッション時のV$SESSION

[DB2]12セッション時のV$SESSION

▲[DB2]12セッション時のV$SESSION

[DB3]12セッション時のV$SESSION

▲[DB3]12セッション時のV$SESSION

期待したとおり「resmgr:cpu quantum」の待機イベントは発生せず、Resource Managerでの制御は行われませんでした。このタイミングのmpstatからは、全てのCPU使用率が100%(99.00以上≒100%)でCPUリソースが全て使えている状況が確認できます。

各データベースで12セッションがCPUを使用している際のmpstat

▲各データベースで12セッションがCPUを使用している際のmpstat

このことより、各データベースでCPUを使用するセッションが16以内であれば、サーバに搭載しているCPUスレッド数を超えて同時にCPUを使用するセッションがあっても、Resource Managerによる制御はされないことがわかりました。

【検証 2】1つのデータベースだけ制限超え
CPUを使用する処理を行うセッションを24:12:12で実行

ここからが本番です。3つのデータベースの内、1つのデータベースでCPUを使用する処理を行うセッションを24まで増やします。残りのデータベースは12セッションのままで制限内のため、制限を超えたデータベースのみResource Managerで制御されることが期待される動作です。

24セッションがCPUを使用する処理を行っているデータベースでは16CPUスレッドの制限を超えたため、Resource Managerによって制御されています。残りの2つのデータベースではそれぞれ12セッションがCPUを使用する処理を行っていますが、制限内のため影響はありませんでした。

[DB1]24セッション時のV$SESSION

▲[DB1]24セッション時のV$SESSION

[DB2]12セッション時のV$SESSION

▲[DB2]12セッション時のV$SESSION

[DB3]12セッション時のV$SESSION

▲[DB3]12セッション時のV$SESSION

この状態でmpstatを確認すると、全てのスレッドが使用率が100%(99.00以上≒100%)でCPUリソースが全て使えている状況が確認できます。

CPUを使用するセッションが24:12:12の際のmpstat

▲CPUを使用するセッションが24:12:12の際のmpstat

こちらも期待通りの結果です。Resource Managerでの制御は制限を超えたデータベースに対してのみ行われています。

【検証 1】、【検証 2】の結果より、データベースごとに16CPUスレッドの制限が行われており、特定のデータベースで制限を超えた場合でも、他のデータベースのCPUスレッド数制限には影響がないことがわかりました。

まとめ:ソケット数の制限が厳しい

データベース(Resource Manager)としての制限は検証結果のとおりですが、移行を検討する際には従来のSEではソケット数は最大4つ(OSにより異なる)までの制限が、SE2で「最大2つ」に変更されていることに注意が必要です。

SE2のソケット数制限

SE2のソケット数制限

SE2のCPUスレッド数制限

SE2のCPUスレッド数制限


既存のSE環境(12.1.0.1まで)で同一サーバ内に複数のデータベースを構築されている場合には、移行前のCPUリソースの使用状況や今後の拡張を考慮した上で移行先のライセンスを検討する必要があります。ソケット数制限によってサーバに搭載するCPUスレッド数を下げざるを得ないケースがあるため、安易にSE2に移行してしまうと【検証 1】のようにデータベースとしては制御されなくてもCPUリソースを使い果たしてしまい期待した性能を得ることができないかもしれません。

制限の内容を見ると、SE1/SEからの移行先としてはSE2ではなく、拡張性の高いOracle CloudやOracle Database Applianceを…という意図が見えなくもないですね。SE1/SE環境からの移行先でお困りのお客様はぜひ一度ご相談ください。


【Oracle SE2】CPUスレッド数制限の動作検証結果は次回が最終回です。RAC環境での動作をご紹介します。

筆者情報

大野 高志

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

2007年にアシスト入社後、Oracle Databaseのサポート業務に従事、現在はサポート対応を行いながら、データベースの運用で発生するトラブルを未然に防げるよう、サポートセンターに蓄積されているノウハウを社内外に伝える活動を行っている。

関連している記事

  • Oracle Database
2016.11.16

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

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

  • Oracle Database
2016.10.27

【Oracle Database】うるう秒の対応

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

  • Oracle Database
2016.09.21

再現ケースを簡単に作成!SQLテスト・ケース・ビルダーの使用方法

再現ケースに必要な情報を一括で容易に取得できる「SQLテスト・ケース・ビルダー」の使用方法を紹介します。

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

ページの先頭へ戻る