Oracle database 12cマルチスレッドを試してみた
12cからの新機能のプロセスのマルチスレッド化を試してみました。
今回はバックグラウンドプロセスではなく専用サーバのスレッド化についてです。
環境はOracle database 12.1.0.2 SE2
マルチスレッドの有効化
初期化パラメータのTHREADED_EXECUTION
とUSE_DEDICATED_BROKER
をtrueにしてOracleの再起動する。
SQL> show parameter THREADED_EXECUTION NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ threaded_execution boolean FALSE SQL> show parameter USE_DEDICATED_BROKER NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ use_dedicated_broker boolean FALSE
sqlplus / as sysdba SQL> alter system set THREADED_EXECUTION=true scope=spfile; SQL> alter system set USE_DEDICATED_BROKER=true; SQL> shutdown immediate; SQL> startup
この時点でOS認証でのログインができなくなるので注意。
パスワードファイルを作成しておいて、これ以降はパスワード認証でログインする。
参考:
THREADED_EXECUTIONでOracleインスタンスをマルチスレッド構成に (コーソル DatabaseエンジニアのBlog)
USE_DEDICATED_BROKERをtrueにすることによって、リスナーは接続を専用サーバープロセスではなく専用接続ブローカに渡してそのブローカが専用サーバーを起動するようになる。
ブローカーの設定は初期化パラメーターCONNECTION_BROKERS
で設定可能。
デフォルトは専用接続ブローカが1となっている。
SQL> show parameter CONNECTION_BROKERS NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ connection_brokers string ((TYPE=DEDICATED)(BROKERS=1)), ((TYPE=EMON)(BROKERS=1))
外部接続を有効にするためにlistener.oraにDEDICATED_THROUGH_BROKER_(リスナー名)=on
追記してリスタート。
vim listener.ora DEDICATED_THROUGH_BROKER_listener=on lsnrctl stop lsnrctl start
リスナーを起動して情報を確認すると、DRCPと同様に専用接続ブローカ(N000)が起動していることがわかる。
$ lsnrctl service インスタンス"orcl"、状態READYには、このサービスに対する2件のハンドラがあります... ハンドラ: "N000" 確立:0 拒否:0 状態:ready CMON <machine: de8f124abb2c, pid: 18988_19012> (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=37710)) "DEDICATED" 確立:0 拒否:0 状態:ready
これでプロセスのスレッド化の設定は完了。
マルチスレッドになっているか確認
複数の端末からsqlplusで接続して確認してみる。
専用サーバのマルチスレッドの場合、
SPIDが同じ値になっているのでOS側で一つのプロセスで動作しているのがわかる。
そして、execution_typeがTHREADとなる。
SQL> select p.PID,p.SPID,p.STID,p.execution_type,p.PNAME,p.PROGRAM,s.program from v$process p join v$session s on s.PADDR = p.ADDR order by 1; PID SPID STID EXECUTION_ PNAME PROGRAM PROGRAM ---------- ------ ------ ---------- ----- ----------- -------------------------- 37 18988 24782 THREAD oracle@host sqlplus@host (TNS V1-V3) 38 18988 24783 THREAD oracle@host sqlplus@host (TNS V1-V3) 39 18988 24784 THREAD oracle@host sqlplus@host (TNS V1-V3)
通常の専用サーバ接続の場合、
SPIDのプロセス番号違っているのでOS側で接続毎にプロセス生成しているのがわかる。
そして、execution_typeがPROCESSとなっている。
PID SPID STID EXECUTION_ PNAME PROGRAM PROGRAM ---------- ------ ------ ---------- ----- ----------- -------------------------- 37 24798 24798 PROCESS oracle@host sqlplus@host (TNS V1-V3) 38 24800 24800 PROCESS oracle@host sqlplus@host (TNS V1-V3) 39 24802 24802 PROCESS oracle@host sqlplus@host (TNS V1-V3)
通常の専用サーバ接続、DRCPとマルチスレッドで比較
マルチスレッドにすることで新規プロセスの生成が抑えられるからログオン数とか上がるのかなと試してみた。
コネクションプール機能がある場合はたぶんマルチスレッドにメリットは少なそうだけど、新規接続切断を繰り返す場合のアプリケーションでは効果があると思う。
通常の専用サーバ接続、DRCPとマルチスレッドで比較してみた。
同時接続数5でトランザクションごとに新規接続、切断を繰り返すテストを実施。
実行時間は10分間で 5回実施した平均値を基に算出。
DRCPの設定はminsize=>30
ですべての接続がプールされているサーバで処理できる設定。
↓結果は具体的な数値はなしで相対的な数値です。
通常の専用サーバ接続を100とします。
専用サーバ接続 | マルチスレッド | DRCP | |
---|---|---|---|
ログオン回数 | 100 | 112 | 121 |
TPM | 100 | 114 | 123 |
TPS | 100 | 106 | 114 |
というように DRCP > 専用サーバマルチスレッド > 通常の専用サーバ接続 という結果になった。
専用サーバのマルチスレッドは通常の専用サーバ接続よりかは良さそうな結果だった。