DB2秘剣シリーズ

2006年8月11日（金）

今回はDB2のプロセス・モデルを説明します。DB2のプロセスは図1のようになっています。 執筆者 春野さくら

図1 プロセス・モデル

ユーザー/アプリケーションがネットワークを経由してデータベースに接続すると、リスナーにより(db2ipccmはNetBIOS,db2tpccmはTCP/IPのListner)コーディネーター・エージェント（db2agent）プロセスが起動されます。SMPマシンの場合、SQL文を実行するために複数のサブエージェント(db2agentp)が起動され、そのエージェントがDB2エンジンに働きかけて、実際のSQL文の処理を並行的に行います。DB2のエンジン内部では、バッファープールを効率的に使うために、プレフェチャー(db2pcfchr)やページクリーナー(db2pclnr)プロセスが稼働され、必要なデータがタイムリーにバッファープールに存在するようにしています。一方、データの一貫性を保証するためにロッガー(db2loggr, db2loggw) がログバッファーの中味をディスク上のログにCommitのタイミングで書き込みます。デッドロック・ディテクター(db2dlock)は、常にデッドロックの発生を監視していて、発見した場合にはデッドロックを解決します。 バッファープールからディスクへはCommitとは非同期でデータの書き込みが行われます。これはトランザクションの高パフォーマンスを保証するために採用されているアーキテクチャーです。

エージェント・プールとは、クライアントの接続要求に備えて、あらかじめ稼働させておく一定数のエージェント・プロセスが常駐するところです。なぜなら、UNIXではプロセスを作りだすForkという作業に大きなCPU負荷がかかるので、大量のクライアント接続要求が同時に起こった場合パフォーマンスに悪影響を与えるからです。このエージェントは実際に仕事をするまではアイドル・エージェントと呼ばれます。db2start時に立ち上げておくアイドル・エージェント・プロセスの数は構成パラメーター(num_inittagents)で設定します。num_poolagentsはインスタン内で存在できるアイドル・エージェントの最大数を設定するパラメーターです。アプリケーションがデータベースに接続して、なんらかの仕事をする時に、もし必要なdb2agentを確保できない場合、db2agentを他から”steal”するか”creation”する必要があります。この場合システム的にはOSのcontext switch率が高くなり、CPU負荷がかかります。図2にdb2agentを確保する順番が書かれています。負荷が軽い順番になっています。そこで、できるだけ”steal”と”creation”が起こらないように、エージェント・プールの数を設定することがパフォーマンスを向上させることにつながるわけです。

1. アイドル
2. エージェント・プールに存在するデータベースレベルのdb2agntp（V8で提供）
3. エージェント・プールに存在するインスタンスレベルのdb2agent
4. 他のプロセスに関連づけられているアイドルプロセス（Stealすると呼ぶ）
5. エージェントを新規に作成（creationと呼ぶ）
   
   

図2 db2agentを取得する順番

しかしながら、多数のユーザーがデータベースに接続するような環境では上記のようなクライアント/アプリケーションとエージェントが1対1で対応づけられるモデルでは、パフォーマンスおよびメモリアロケーション上非常に負荷が高くなるので、V8ではConnection Concentratorと呼ばれる新機能を提供しました。従来は、N個のデータベース接続に対してN個のコーディネーター・エージェントを必要としていたのに対して、Concentratorを使うとN個のデータベース接続に対して、N個より小さい数のコーディネーター・エージェントですむようになりました。つまり、複数のユーザーやアプリケーションが同じコーディネーター・エージェントを使えるようになったのです。

図3 Connection Concentrator

このconcentratorを使用可能にするには、単に、インスタンス構成パラメーターを　max_connections > max_coordagents　に設定するだけです。

db2update dbm cfg using max_connections 10000 
max_coordagents 100

concentratorを使用した場合、新しいトランザクションが起動されるとディスパッチャー（db2disp）がエージェントを選びます。

図4 Concentratorのプロセス・モデル

V8では、その他にもアプリケーション・グループという考えが提供されました。これは多数のユーザー/アプリケーションがメモリーを有効に使うために導入されたものです。SQLのワークプレースとその他のメモリー構造がアプリケーション間で共有されます。アプリケーション・グループ数はDB2開始時に1から始まり、必要に応じてDB2によって自動的に追加されます。1グループのアプリケーション数はインスタンス構成パラメーターのaggroup_mem_szとapp_ctl_heap_szで設定されますが、このアプリケーション・グループとconcentratorを組み合わせて使うことも可能です。

図5 アプリケーション・グループ

ユーザー数が大きい場合は、concentratorを使うことをぜひ考えてください。　また一つのアプリケーション・グループは最低50-150アプリケーション数をターゲットにしてください。またV7のクライアントはconcentratorを使えないので、concentratorを使う場合は避けてください。

さて今回は新しいインターナルの巻だったがどうじゃったかの？　また新たに修行の意欲がわいてきたかな？　それではさらばじゃ。

上に戻る

上に戻る