CMS Tuning: maxobjectsincache and MaximumObjectsToKeepInMemory

I think all Business Objects administrators and developers share at least one goal; they all want their XI system to perform at the best of its ability to realize its full potential. If you have this goal keep reading and please share any comments you might have as well.

Observing/Measuring Tuning Impacts

Tuning is a very delicate process. We all wish it were easier and more straightforward, but one truth stands in the way of this: the only way to know for certain the impact of any tuning change is to compare the system’s performance before and after the change. This fact present problems on live production systems because the use of the system constantly varies in load volume and the kind of work being done. Formal load testing attempts to overcome this problem using virtual users with tools such as Load Runner; however, while providing consistency these tools often fail to replicate real world usage. In the end, the best a Business Objects administrator can do is to run load tests and also observe live/organic system performance over time.

CMS Parameters Good For Everyone

The truth is that there are some Central Management Server (CMS) settings which given adequate hardware and database configurations, will almost always benefit all Business Objects XI systems. The following is the first one that comes to mind:

Playing With the CMS Cache

The cache is the first place you should focus. No CMS running on average server hardware will be harmed by pushing the memory cache parameter to the maximum and most systems will benefit. The only caveat here is that if your system has limited memory (you will know by watching RAM utilization) you may steal away your BOXI server’s scarce memory which is being used by the CMS to process its very MANY queries. Increasing the maximum number of objects allowed in the CMS memory cache will reduce the number of database calls required and according to the “BusinessObjects Enterprise Adminstrator’s Guide” for BOE XI 3.1 (page 656), this will greatly improve performance! There are two places to configure this setting:

Changing the Business Objects Registry Parameter: MaximumObjectsToKeepInMemory

The registry is one place where the change can be made cleanly and hidden. It is more difficult for someone to change this setting, but it is also more likely to be forgotten and taken for granted when it is placed in the registry. Also, keep in mind, if you recreate a Server Intelligence Agent (SIA) then all registry values will be reset to default settings.

The key to change is under the CMS’s instance and it is named “MaximumObjectsToKeepInMemory“. It is set to 40000 by default. The upper limit, which you should shoot for, is 100000. My server’s underutilized RAM and I wish it were higher.

The CMS Command Line parameter: maxobjectsincache

The other place to enable this parameter is in the CMS server’s command line. This is a less conspicuous place to make the change and I believe that any change made here overrides the corresponding registry parameter. The parameter is called “-maxobjectsincache #” (the admin guide shows it in all lower caps but letter case does not seem to matter). You invoke this by adding in CMC to the command line (or in XIR2 in CCM) the text ” -maxobjectsincache 100000″. Just be sure to place a space between this and any other parameters you might find there already.

Please Note: The command line parameter will override the corresponding registry setting.

Please share any related experiences with this parameter and any comments or questions you may have.

Recommend Reading: CMS Tuning: ndbqthreads or Number of Requested Database Connections

Enjoyed this post? Share it!

 

10 thoughts on “CMS Tuning: maxobjectsincache and MaximumObjectsToKeepInMemory

  1. Hi,

    Do you know how to change these settings when BO XI 3.1 is deployed on a Unix/Linux server?

    Thank you.

  2. Hi Marek, the command line parameters can be set in CMC on the CMS server. However, I prefer to use the registry settings which are located here on BO XI 3.1:
    /bobje/data/.bobj/registry/software/business\ objects/suite\ 12.0/cms/instances/.cms

  3. My project was advised by a SAP consultant to update the ccm.config and add “-maxinfoobjectsincache 250000” within the CMS command line as this parameter increases the number of cached infoobjects from 10,000 (default) to the number in the BOESystem Database which is 250,000.

    But this is a different parameter name, this Tip gives -maxobjectsincache not -maxinfoobjectsincache. Which one is correct please? We are using XIR2 and Solaris Unix.

    Grateful for any help

  4. Hi AndyOB, I am so glad you found this article. Your paid consultant is wrong and our free article is correct. That sounded smug, didn’t it? Nevertheless, it is true. To confirm my statement, you could just do a Google search for each parameter name independently. You will find that “maxobjectsincache” will show you many results and “maxinfoobjectsincache” will show you nothing.

    On another note, I dispute the claim that you can successfully set your value above 100,000. I have been told by many SAP BO senior engineers that 32-bit BusinessObjects cannot handle more than 100,000 effectively. I have not tested this, but I would ask your consultant to check with his colleagues. No worries, I myself have worked with paid consultants from SAP that produced terrible/doubtful sizing recommendations. Sometimes you just are not lucky.

  5. FYI: BOE 4.0 maxobjectsincache is set to 100 000
    You can use the Monitoring component in the CMC to create a watchlist based on the 2 metrics: No in system and No in Cache to notify you when you exceed the threshhold.

  6. I know this article is old, but we are currently tuning our BI system.

    Does the maxobjectsincache command line switch need to be enabled after every reboot? I can’t seem to find any command that tells me the current settings of the CMS command line parameter.

  7. Very useful and informative. Thanks for posting this. Appreciate your in-depth knowledge on this article.

Leave a comment

Your email address will not be published. Required fields are marked *