COGNOiSe.com - The IBM Cognos Community

IBM Cognos 8 Platform => COGNOS 8 => COGNOS 8 Administration => Topic started by: mariorubbo on 08 Jun 2010 04:05:57 PM

Title: C8 capacity planning
Post by: mariorubbo on 08 Jun 2010 04:05:57 PM
I've read repeatedly recently that a server should have 2GB of RAM for every CPU core - therefore a 2CPU machine should have 4GB of RAM and a 4CPU machine should have 8GB of RAM. 

However, I've always heard that it is not beneficial to configure the JVM via Cognos Configuration to use more than 1GB because the memory used by java.exe + the sum of memory used by the BIBusTKServerMain.exe processes should not exceed 2GB.  Based on that, I always assumed that an App server would need no more than 4GB (2GB for OS, 2GB for C8).  Any additional memory on the machine would be unused by C8.  Therefore, I would recommend installing another instance of C8 on that machine to take advantage of the additional memory.  Now I am questioning that recommendation.  Does anyone have a comment?
Title: Re: C8 capacity planning
Post by: smiley on 08 Jun 2010 04:33:53 PM
java.exe and bibus are 32 bits processes (the java.exe from the 64 bits C8 version is not)
That means each can allocate 2 gig on their own.
So if you have a dual quadcore in there, get 16 gig memory, and then run win2k 32 bits enterprise edition, or the 64 bits version of the OS.

The bibus can allocate 2 MAX, thus only large reports and quite a number of low affinity requests can saturate the 2 gig.



Title: Re: C8 capacity planning
Post by: mariorubbo on 08 Jun 2010 07:49:44 PM
But again, I was told that each BiBus process runs inside the JVM heap and therefore each process's memory usage has to be balanced with the memory used by java.exe and that the sum shouldn't be more than 2GB or the JVM will start swapping to disk.  I also read somewhere that there was no reason to allocate more than 2GB to the JVM because beyond that, Java gets inefficient with garbage collection, etc.

Your email says that each BiBUs process gets its own 2GB of RAM + java.exe gets its own 2GB.  If java.exe gets its own 2GB, why do I read so often about not configuring the Maximum Memory in Cognos Config beyond the Medium Config which allocates about 1GB for the JVM?  Why does the Large Configuration only go as high as 1152MB?  Why not configure it as high as 2GB since that only accounts for the memory used by java.exe and not the memory used by the BIBusTKServerMain.exe processes?
Title: Re: C8 capacity planning
Post by: smiley on 09 Jun 2010 02:56:54 AM
Because the large configuration is needed for enterprise rollouts.
The large stack can handle about 1700 concurrent users. Once you need more, you need to use the 64 bits version.
These people are running dedicated Content managers, and dedicated dispatchers.

Most people run plain vanilla 4 gig mem machines, to be able to run the cheap standard OS, which is limited by 4 gig total.
For those, they need to balance between java and bibus.

So if you're starting from scratch, and can choose whatever you want, get a a dual quadcore server with 16 gig memory, and install the 32 bits version of C8 on it on top of 2k8 x64 standard.

The hardware/software gives you best bang for bucks, and the 32 bits C8 version seems to give less problems then the 64 bits version.
(no details on that; just read back on the forum on that part)
 
Title: Re: C8 capacity planning
Post by: mariorubbo on 10 Jun 2010 07:18:09 AM
So for a dual quadcore server, would you change the Maximum number of Report Processes setting to 16 (2 processes * 8 CPUs)?
Title: Re: C8 capacity planning
Post by: smiley on 10 Jun 2010 04:44:03 PM
14. That way you "reserve" 2 for the java stack.
Title: Re: C8 capacity planning
Post by: mariorubbo on 11 Jun 2010 07:58:19 AM
thanks for the enlightenment.
Title: Re: C8 capacity planning
Post by: mpflug on 12 Jun 2010 11:38:30 AM
Note that the 14 includes both batch and interactive report services.  Depending on your needs your actual mix of the two will very. 

Also, when they say per CPU they're talking CPU core not physical CPU.