If you are interested in maximizing the performance of your system please review this article and also its companion: CMS Tuning: maxobjectsincache and MaximumObjectsToKeepInMemory.
Observing/Measuring Tuning Impacts
The parameter discussed in this article requires more tuning and closer observation than other CMS Tuning technique may require. I highly suggest that you do a load test and that you have a serious discussion with your DBA on tuning this parameter.
CMS Database Connections, a.k.a. ndbqthreads
The number of requested database connections is another place you might improve performance. This setting is one that will only improve performance at times of high load on the CMS. It prevents your CMS’s number of connections to its database (a.k.a. CMS InfoStore, metadata repository; don’t confuse this with report data source connections) from becoming a bottleneck to your system. It opens more conduits between the CMS and the CMS’s database. This setting will be limited by the number of connections that your CMS’s database accepts, so be careful not to exceed that number (this is something that a DBA or DBA tools can help determine. This setting is controlled by different parameters depending on your version of Business Objects Enterprise:
BO XI 3.1: System Database Connections Requested (CMC Property)
In Business Objects XI 3.1 you will find in the properties of the CMS (CMC > Servers > Your_CMS > Properties) a parameter/setting named “System Database Connections Requested“. This setting is set to “14” by default. I have heard that 99 might be the maximum, but your database’s configuration will probably restrict you before you reach 99.
A Quick CMS DB Thread Sizing Calculation
A recommended baseline is to have one connection for every 20 expected peak concurrent users. I am not speaking of the “Concurrent User” versus “Named User” user type, but I am speaking of the max number of users that you expect to access the system concurrently at any one point in time. Take this number and divide it by 20. Now take that number a divide it by the number of CMS that your cluster is running. The final number is the value that you should put in the “System Database Connections Requested” parameter value of each CMS in the cluster. This a good baseline for you to begin testing (testing this one can be elusive and will certainly require DBA skills to detect the activity on all open connections). If the per CMS number you calculated is less than the default 14 then you could reduce this setting and test for any effects; you consume less database connections which other applications or processes might appreciate.
XI R2: ndbqthreads (CMS Command-Line Parameter)
In XIR2 there is this thing called NDBQ threads. According to the Administrator’s Guide the setting exists in BO XI 3.1 as well (although I don’t understand how it plays/conflicts with the “System Database Connections Requested” setting there). The setting is made in the CCM on the command line for the CMS. That parameter is specifically “-ndbqthreads #“. I believe that “2” is the default setting and I know that “10” is the maximum (even in XI 3.1 go figure). This can be sized with the same calculation given above, but your limit will still be 10. Given this limit, some Business Objects administrators will choose to add a CMS to the cluster just to be able to add more CMS DB Connections to the cluster. It is possible that the limit of “10” does not apply to Business Objects XI 3.1 as the Administrator’s Guide states. It certainly would not be the first error/omission in the guide.
I am having issue with our BO environment with the system freezing a locking up. Both the SIA and Tomcat server are running when you check CCM. I am curious would this issue be caused by the requested connections being to low? It is set to 14 and we have about 80-100 connections?
Hi Alex, when you say you have 80-100 connections I am assuming that you mean that either you have 80-100 universe connection objects or that your peak usage is at 80-100. Either way, I don’t think having your requested connections set low would be the cause of the system freezing up; however, the only way to know for sure is to have a DBA take a look at the time of the freezing up. The CMS sends lots of very quick SQL statements to the CMS database and it is possible that if you have this number set low you could reach the point where your DB is queuing up those thousands of quick SQL statements but I would not expect to see this happen unless you you had at least 280 (14 x 20) very active users on a single CMS cluster set to 14 requested connections.
Hi Julian ,
We Have SAP BO 4.0 with 2 CMS in cluster. We are facing high CMS query response time alert from one of the CMS. The no of ndbqthreads or Number of Requested Database Connections are 14 on both the CMS.
Could you please suggest what could be reason for this.