We're running with 2008 SP1 64-bit app server and console servers. Whilst the system doesn't seem to be particularly quick, I had put it down to the 8.0 UI and the fact that we have a VM database (it is a dev environment). We are in the process of installing the production environment, so should have a more realistic reference there.
There are some issues with some of the NSH libraries on 64-bit 2008 systems though, which should be fixed in SP4 when it comes out. These probably don't affect the performance though.
We have 2 Application Servers 188.8.131.526 (SP3) running on Windows 2008 SP2 x64 (in a virtual environment, ESX farm is not over-committed) with a load balancer between RCP Client Console and Application Servers. Additionally we are using MS SQL Server 2008 Standard Edt. which seems to be ok. The DB is in the same network as the Application Servers...
Now here comes the problem, if we open the Server Automation Console 184.108.40.2066 with the "BLAdmins" role, it takes 1-2min to open a server. But if we are using a role which doesn't have much permissions, i.e. "solaris viewers" (self created) it takes less than 3 seconds to open the same server for live browsing.
Does anybody know where I should concentrate further analysis?
We analyzed the Application Servers performance counters and made tests on the ESX host so far... Without any results. The network shouldn't be the problem because we installed the Console on the Application Server as well with the same behaviour...
Thanks in advance...
You could try and increase the desktop heap size for the RCP Client Console. This can be increased by modifying the launcher.ini file which is in <8.0>/CM/RCP directory.
In this file, you will find the following line -
Increase it to 512M first. Restart the application server and check the console performance. If it's still slower than you expected, you can increase it to 1024M. For me going from 256M to 1024M made about 20 seconds of difference in RCP Client Console response.
Thanks for the fast response.
Unfortunately the performance is still bad. We actually don't know why? If we use a lower priviledged role, not BLAdmins, i.e. Windows Admins, even the RBACAdmins runs fast, the console speeds up and we are able to work normally... With BLAdmins role, we can't do anything because of the slow performance. Sometimes the console becomes white and in the header we see the "Not respondig..." tag. This occurs only with BLAdmins role.
Is there maybe something wrong with the indexing for BLAdmins in the DB?
SP4 is coming out towards the end of the month and should address many performance issues. So I hate to say 'wait for the service pack' but that may be the option here.
Also, when you change the heap size on the rcp client, you don't need to restart the application server.
Did you run Application Server Diagnostics available in 8.0 console?
For me, the diagnostics showed some connection timeouts with the db and ORACLECHECKNUMBERPROCESSALLOWED was less than what it should be. We are not sure yet but we do think this could be cause of the slowness in our environment.
We will make further progress on Monday on this issue. I will let you know if we see a better performance by the RCP Console.
Unfortunately there is no such solution available for MS SQL Server. The embedded function is only for Oracle. If I run the diagnostics, Oracle DB steps will be skipped... Does BMC implement this function for MS SQL in a later release?!
Anyway, thank you for your thoughts and hints... I opened a case. Don't know if I get something useful...
As I know SP4 was coming out at the end of June.
Do you know when it will be delivered?
SP 4 should be released on July 9th...
Finally we found out what causes the delay in the console. Bad SQL Queries were the reason and BMC finally going to fix it in SP 5 which should be released July 31 2010.
As workaround I got the sqlmap.properties file which you should replace in every instance of the deployment folder... Ask BMC Support if you also need this workaround or wait until SP 5 gets released.
This has only been tested with Windows Server 2008, SQL Server 2008 and BladeLogic Server Automation Suite 220.127.116.112, but I guess it works with all 8.0.0.xxx versions.