A guest post from Will Gillen, a SiteScope power user. Will presented at HP Discover and is contributing to the blog to share his expertise to a broader audience. -Sonja
SiteScope allows for a large number of configurable settings for different environments based on size, servers, resources and other performance related items. I’ve found that using a Windows installation gives the most flexibility and appears to get the most attention from HP development and product direction. I’m not saying the other OS installations are ignored, but from my experience it’s easiest to work with a Windows install. (which was hard for me to come to terms with since I’m a UNIX guy at heart).
When we first decided to use SiteScope as an enterprise monitoring tool, we immediately started using SiteScope for Solaris and Linux. We quickly ran into performance issues with things like file handles and other OS level restrictions that we couldn’t easily fix (due to lack of root access). HP made the suggestion that we try the same configuration on a Windows server and to our dismay it worked great out-of-the-box on Windows. Now at this point we were getting good results but not what we had expected and not nearly what HP had advertised (at the time I think it was something like 16,000 monitors and 2000 / min).
The first thing to run is the sizing option in the config tool (start à programs à HP SiteScope à config tool)
Increase JVM heap to 1024 MB (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SiteScope\serviceParam)
-Xmx1024m -Xms1024m -Xmn160m
Increase Desktop Heap to 2048 MB (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows)
Increase number of file handles to 18000 (HKEY_LOCAL_Machine\Software\Microsoft\Windows NT\CurrentVersion\Windows\USER\ProcessHandleQuota)
Change that value from 10000 to 18000
We spent a lot of time playing with these settings to find what worked for us so I would suggest doing the same.
One more registry setting which seemed to help us with SiteScope (and the server itself) running out of TCP connections:
This is a good starter but there is still more to do based on your requirements.
We use a lot of SSH remotes so we started using the default SSH connection per remote as 3 but increased that to 5 (and sometimes 10). The driver here is in the SSH stats screen you can see which servers spend the most time on SSH. We use this screen a lot to adjust the SSH connections per remote.
SiteScope also offers a bunch of configuration items in the UI which help with the overall performance. Now I will be honest, we spent a lot of time (too much time) messing with these settings like process pool and perfex but quickly realized that the out-of-the-box settings worked best for us. But, like I said before, all environments are different so it’s worthwhile to experiment with these settings and see what fits for you.
Finally and frankly the most important thing to consider is geography. Initially our deployment of SiteScope was completely oblivious to server to remote location and we learned later on that we could get at least 4 times the response time per remote when the server and the remote are in the same location. So now are next project will be to move our monitors around based on the physical location of each remote and co-locate the SiteScope servers so they have less distance to travel to capture the data we need. We are expecting to cut our SiteScope server footprint by 30% -50% with this move.
With these adjustments I mentioned we are now seeing performance of approx 2000 monitors per minute and monitor counts of about 16000 per SiteScope server.
I welcome any questions, comments or suggestions for follow up blog posts.
Sonja is a Product Marketing Manager for the HP Software Operations Center portfolio of products. She has 19 years of product marketing, product management, engineering, and consulting experience with privately-held, start-up, and Fortune 500 companies. Sonja has been responsible for positioning, messaging, strategy, and go-to-market programs for both consumer and B2B product lines. Companies that she has worked for include InstallShield, Loudcloud, Sun Microsystems, and AT&T.