概要

最近読んだ、各ベンダーのBIツールを評価するアンケートをエンドユーザーに行った結果によると、Cognosの強みは、多くの同時接続ユーザーにおけるレポートの並列処理を行う能力と答えているユーザーの方が多いようで、多くのBIツールの中でトップクラスの評価を受けてました。
特別に意識する事なく、こんなものだろうと今まで使っていましたが、せっかくなので何かしら関連した情報を投稿しようと思い、最近質問を受けた、Cognos BI&Analyticsでの同時実行処理能力に対する、パラメーターチューニングの考え方を投稿しておきます。

Cognosのレポート実行時の動作

下図はCognosのDispatcherとReport Serviceプロセスを説明している図ですが、Cognosのレポート実行は、ブラウザ上でレポート名をクリックしレポートを実行すると、指令がGateway(WEBサーバー)を通り、図のDispatcherを通り、Dispatcherから空いているReport Serviceプロセスに振り分けられ、基本的にReport Serviceプロセス内の親和性の低い接続(スレッド)1個を使用してレポートの実行処理が行われます。

Report Serviceプロセスの中には、親和性の低いスレッドと親和性の高いスレッドを持ちます。
この2つのスレッドの違いは、初回のレポート実行は親和性の低いスレッドを用いて行われレポートが表示されます。
そのレポートの中で、次ページへの遷移やPDF出力などの初期表示の継続として行われる処理は親和性の高いスレッドを用いて行われます。

Cognosにおける同時処理能力は、Report Serviceプロセス数 x 親和性の低いスレッド数で算出されます。
全てのプロセスの全ての親和性の低いスレッドが埋まっている状態で、次のリクエストが来ると、スレッドが空くまで処理はキューにためられ待たされます。※タイムアウト指定のパラメータあり

Cognosの並列処理のパラメーターチューニングの考え方

Report Serviceプロセスの数は、CPUコア数 x 2が一般的なガイドとなります。
Report Serviceプロセスは32bitのプロセスのため、プロセスで使用できるメモリーは2GBに制限されます。
Report Serviceプロセスの使用メモリーが2GBを超えると、Report Serviceプロセスがダウンし、このプロセスを使用していたユーザーのレポート実行はエラーとなります。
親和性の低いスレッドの数は、この2GBメモリーの制限を考慮して、環境ごとに全スレッドの合計使用メモリーが2GBを超えないように、スレッド数を検討します。
下の図は、Report Serviceプロセスのプロパティですが、赤枠の箇所でReport Serviceプロセス数を、青枠の箇所で親和性の低いスレッドの数を指定します。
起動中のプロセス内のスレッドの半分が使用されている場合、新規にプロセスを起動する動作になるようです。

補足

というのが基本ですが、動的クエリー(DQM)モード限定であれば64bitの選択も可能とか、

レポートにCognos10のチャートが含まれる場合、Graphic Serviceのプロセス数やスレッド数もチューニングの対象になりますので、このあたりも考慮に入れて頂ければと思います。

補足2

もっと細かい調整も可能ですので、こちらもご参照下さい。
Cognos のReport Server(BIBusTKServerMain)プロセスの動作調整
https://qiita.com/shinyama/items/40191bd583c0852e56c4