DB2 コネクションコンセントレータを試す

注意：相変わらず適当なことを書いている可能性がありますので
　　　今一度テスト環境で確認等をしてからご使用するなりしてください〜

前から気になっていた「コネクションコンセントレータ」「Connection Concentrator」を
試してみました。

アプリケーションがDBに接続する際に、基本的にコネクションが張られると
db2agentが１つ立ち上がります。
(イメージとしてはapacheのhttpdに近いです)
ただ、db2agentもしっかりしたプログラム(9.5以降はスレッド)なので
それなりにメモリーもとりますし、OS上ではプログラム(スレッド)が
増えます。
IBMの説明では、業務アプリで、クライアントがすごい台数あり、
始業時刻になると一気にPCの電源が入りアプリが立ち上がったとたん
DBへの接続がガンガンきて不安定になる・・のを回避できるんだそうです。
自分たちであれば昨今のフレームワークだと、ブラウザからのアクセスがあったら
とりあえずDBに接続しちゃうものもあるようで、
結局処理的にはQueryを投げずに終わるパターンもあるんじゃないかと思います。

そんな「結局何もしない接続」でもDB側は律儀にdb2agentがあらがってきますので
DB側の負荷は少なからずあったりします。
アプリ側で気をつければいいのですが、もうどうにもならんｗ
なんて話はよくあるわけでｗｗｗｗ

で、1つの解決策としてConnection Concentratorを使って
接続口でdb2agentへの接続を集約させようというものです。
(connection poolingの考えですね)

たとえばクライアントが500台ほどあって
でも、同時に処理が走るのはせいぜい50くらいなら
agentの数は100で、接続数は1000くらいでいいかな？って
設計したとしたら

DB2 9.1以前では
db2agentの数はMAXAGENTSで設定しましたので

db2 update dbm cfg MAXAGENTS 100 MAX_CONNECTIONS 1000

DB2 9.5では
MAXAGENTSが無くなりMAX_COORDAGENTSがそれになりますので

db2 update dbm cfg using MAX_COORDAGENTS 100 MAX_CONNECTIONS 1000

という設定をします。

これでいくら接続があってもdb2agentは100(くらい)しか上がってこないので
サーバもある程度楽になってくれると思います。

では、実際に試してみました。
phpでdb2_connectを一気に200ほど張るコードを書いて

・接続とエージェントが同数＝Connection Concentratorが無効の状態

db2 update dbm cfg using MAX_COORDAGENTS 1000 MAX_CONNECTIONS 1000

と
・接続1000まででエージェントが100＝Connection Concentratorが有効の状態

db2 update dbm cfg using MAX_COORDAGENTS 100 MAX_CONNECTIONS 1000

の2パターンを試してみました。

まずは
Connection Concentratorが無効の状態の状態でコードを走らせると
一気にagentがあがりました。

$ db2pd -edus |grep db2ag

229       2558520208     3843           db2agent (TESTDB)                      0.000000     0.000000
228       2559568784     3842           db2agent (TESTDB)                      0.000000     0.000000
227       2528111504     3841           db2agent (TESTDB)                      0.000000     0.000000
226       2575297424     3840           db2agent (TESTDB)                      0.000000     0.000000
225       2576346000     3839           db2agent (TESTDB)                      0.000000     0.000000
224       2577394576     3838           db2agent (TESTDB)                      0.000000     0.000000
223       2578443152     3837           db2agent (TESTDB)                      0.000000     0.000000
222       2579491728     3836           db2agent (TESTDB)                      0.000000     0.000000
221       2580540304     3835           db2agent (TESTDB)                      0.000000     0.000000
220       2581588880     3834           db2agent (TESTDB)                      0.000000     0.000000
219       2582637456     3833           db2agent (TESTDB)                      0.000000     0.000000
218       2583686032     3832           db2agent (TESTDB)                      0.000000     0.000000
217       2584734608     3831           db2agent (TESTDB)                      0.000000     0.000000
216       2585783184     3830           db2agent (TESTDB)                      0.000000     0.000000
215       2586831760     3829           db2agent (TESTDB)                      0.000000     0.000000
　・
　・
　・
まだまだ続く・・

で、Connection Concentratorを有効にすると、200の接続があったにもかかわらず
agentが3個しか上がってこず、これは期待できそう〜

$ db2pd -edus |grep db2ag

56        3068128144     3455           db2agntdp (TESTDB  )                   0.350000     0.140000
55        3067079568     3454           db2agntdp (TESTDB  )                   0.060000     0.020000
17        3079662480     31755          db2agntdp (TESTDB  )                   1.690000     0.950000

ちなみにDB2 9.5はスレッドモデルに移行したためpsコマンドではdb2agentが確認できないので

db2pd -edus

ってやるとdb2関連のスレッドがわかります。

Connection Concentratorもすべてもアプリケーションに適応できるわけではないので
その点はご注意を・・

参考記事：
http://www.ibm.com/developerworks/jp/db2/library/dataserver/sakura/hiken/06.html