Administration - Processes and Connections

[Bod]

Could you please validate my understanding...

The following line in Cognos Administration refers to how may BIBusTKServerMain processes can be spawned on the server
--Maximum number of processes for the report service during peak period

Whilst this line would refer to how many connections (reports) can be handled by each of the BIBusTKServerMain processes
--Number of low affinity connections for the batch report service during peak period

So if we did the following we would see 2 processes each running 3 reports and so 6 reports in total can run concurrently.
--Maximum number of processes for the report service during peak period = 2
--Number of low affinity connections for the batch report service during peak period = 3


If the above is correct, why would you not do the following instead.  The advantage would be that we would have visibility on what effect a particular report is having on the system in terms of memory, cpu, network and disk.  Each BIBusTKServerMain process would refer to just 1 report and if there is an issue you would be able to end the process in Task Manager without affecting other reports.
--Maximum number of processes for the report service during peak period = 6
--Number of low affinity connections for the batch report service during peak period = 1

Currently we see the CPU for each BIBusTKServerMain hitting 25% as a maximum for good periods of time, where I believe the Cognos Servers are performing local processing.

We have 4 dispatchers in our Windows setup (only 3 of them configured for Background (BatchReportService) whilst all 4 can take Interactive requests)
we are using Intel Xeon E7-8891 v3 CPUs
2 sockets and 8 Virtual Processors.
What other advice/information do you have with regards to the 2 settings above please?

thanks for any advice

[MFGF]

Could you please validate my understanding...

The following line in Cognos Administration refers to how may BIBusTKServerMain processes can be spawned on the server
--Maximum number of processes for the report service during peak period

Whilst this line would refer to how many connections (reports) can be handled by each of the BIBusTKServerMain processes
--Number of low affinity connections for the batch report service during peak period

So if we did the following we would see 2 processes each running 3 reports and so 6 reports in total can run concurrently.
--Maximum number of processes for the report service during peak period = 2
--Number of low affinity connections for the batch report service during peak period = 3


If the above is correct, why would you not do the following instead.  The advantage would be that we would have visibility on what effect a particular report is having on the system in terms of memory, cpu, network and disk.  Each BIBusTKServerMain process would refer to just 1 report and if there is an issue you would be able to end the process in Task Manager without affecting other reports.
--Maximum number of processes for the report service during peak period = 6
--Number of low affinity connections for the batch report service during peak period = 1

Currently we see the CPU for each BIBusTKServerMain hitting 25% as a maximum for good periods of time, where I believe the Cognos Servers are performing local processing.

We have 4 dispatchers in our Windows setup (only 3 of them configured for Background (BatchReportService) whilst all 4 can take Interactive requests)
we are using Intel Xeon E7-8891 v3 CPUs
2 sockets and 8 Virtual Processors.
What other advice/information do you have with regards to the 2 settings above please?

thanks for any advice

Hi,

The number of report processes multiplied by the number of connections per process gives you the maximum number of reports that can be run concurrently. You shouldn't just arbitrarily decide how many of each to configure, though. I can see that from a simplistic standpoint, 8 concurrent reports might be assumed to be the same server load regardless of whether it is 1 process with 8 connections, 2 processes with 4 connections, 4 processes with 2 connections or 8 processes with 1 connection, but this really isn't the case. A report process is a 32-bit executable, and has a finite memory limit and a known CPU requirement which have both been taken into account in IBM's best practice guidelines. Unless you stick to these, you run the risk of things like hitting the CPUs too hard, running out of available memory, or grabbing CPU cycles or memory where you don't need to.

What IBM recommends for interactive report services is the following:

Set the number of report services to 2x the number of virtual processors
Set the number of low affinity connections per service to 4
Set the number of high affinity connections per service to 1
If you are using packages and reports utilizing Compatible Query Mode, make sure you have at least 2Gb free memory per report service, or 1Gb if using DQM

In following these guidelines you stand the best chance of having an appropriately tuned Cognos instance, which makes best use of the available hardware.

Just to make it clear, I'm speaking here from learning and experience rather than on behalf of IBM - I'm in no position to do the latter. :) I'm just passing along what I learned from Cognos and IBM over the years...

Cheers!

MF.