Setting the correct maximum number of process for report service

[sdf]

Just want to check or get feedback from experts.
i am trying to propose tuning settings for a deployment that has 2 dispatcher server.
Each dispatcher server has 32GB RAM with 4 CPU cores.

Here's my recommendation based on 360+ users :

maximum memory for Websphere Liberty profie : 16GB (could be more)

Number of high affinity connections for the report service during peak period = 2
Number of low affinity connections for the report service during peak period =8
Maximum number of processes for the report service during peak period=4

I reiterated these are just the starting configurations. I believe based on the current server resource we could still increase these settings.
But i would like to test our first how heavy the users will be.

Would like to get you expert's view and opinion.

Thank you.

[dougp]

Some of the following is guess work.  Your mileage may vary...

4 physical cores or 4 logical cores?  Windows (and I assume Linux) will use hyperthreading (or...?) to turn 4 physical cores into 8 logical cores.
Or is this a VM with 4 "cores" assigned?

With 4 cores, you should be able to run 4 BI Bus processes (Maximum number of processes for the report service during peak hours).  But that's for CQM.  If you are also using DQM, the query service will be competing with that.  Also, the operating system may need to compete for resources.  So, if you have 8 logical cores, you could reasonably have up to 6 BI Bus processes, but if you have 4 logical cores, maybe 3 is better.

On my system, I have about 2500 users total, 250 users per day, and have (rarely) seen a max of about 20 concurrent users (actively running reports at the same time).  I use 4 processes and 4 connections per process (so I may have had 4 users queued for a few seconds at one point).  I only run into CPU capacity problems with a Cognos bug condition is hit.*  Other than that, I'm usually running at about 5% CPU usage.

My main resource problem is the temp space required when Cognos is compiling a large CSV or Excel file because a user decides Cognos is a good ETL tool.


*  Filter Condition dialog against a field with many distinct values in Cognos 10.2.1 - 11.0.13 can cause 100% CPU usage.  It's really fun when a classroom full of users all do this at once.  100% of all CPUs are used and all I can do is unplug the server from the power grid.  I have verified it is fixed in 11.1.7.

[sdf]

thanks Dougp for your insight.

Yes, it will be a VM with 4 cores 8 processes.
Im sure it will be CQM and DQM so i guess with this server capacity my proposal would be just fine.

My main resource problem is the temp space required when Cognos is compiling a large CSV or Excel file because a user decides Cognos is a good ETL tool.


*  Filter Condition dialog against a field with many distinct values in Cognos 10.2.1 - 11.0.13 can cause 100% CPU usage.  It's really fun when a classroom full of users all do this at once.  100% of all CPUs are used and all I can do is unplug the server from the power grid.  I have verified it is fixed in 11.1.7.

ugh! tell me about it! i have several customers doing this. Just imagine they are running large Excel file and running their datasets refresh all at the same time. Worse, sometimes the temp files are lingering even after the report/dataset have finished execeuting. Sometimes even sql process lingers because of this. That's why i always watch out for the temp dir size and cleans them periodically.

I have a system on 11.0.13 as well. So i feel you!

[dougp]

Right.  Cognos will frequently not clean up its own messes.  I have a routine that runs daily that deletes anything over 3 days old from the temp folder.  I also track Windows resources graphically by using Performance Monitor to write the data to a CSV file every 15 seconds, 12 hours a day, and a web page for the presentation.  That way I know if my Temp drive (I have a separate drive just for Cognos temp) is filling up or if Filter Conditions is attempting a hostile takeover of the CPUs without needing to crack open Remote Desktop.