Are there standard maintenance/cleanup procedures we should be performing on our BES server?
We regularly delete old actions and computers from the console. Is there something we should be doing to remove this information from the database to speed up server performance? It seems certain web report queries take longer than they should.
It also seems clients are slow to report into the server. Even though the report interval is set to 30 minutes, their last report times in the console can be an hour old or more some times. We have a relay or 2 on every subnet, and the only clients reporting directly to the main bes server are the relays.
Can anyone recommend some performance boosting maintenance procedures?
Deleting actions is one of the most important things to do to keep your systems “clean” because it is a major part of the reason why BES Console memory footprints grow.
Normally, the database is not part of any performance bottleneck in the system because our databases are relatively small (a few GB) for most deployments. Remember that we design the system scale very high and we have several customers with around 200,000 computers pointing to a single BES Server. Even at the highest scale, these customers can push out actions to deploy to all computers in a few minutes.
The main areas where you feel the “hurt” of performance is when your BES Console computers don’t have enough memory or have a slow connection. Also, sometimes there is an issue on one of the components that causes some extra slowness.
Rad, a tool to delete old actions is straight-forward and we can hopefully provide that soon.
dgibson, how many open actions do you have? Lots and lots of open actions will make the BES Clients slightly slower to respond in general. Also, how big is your “FullSiteURLSize” at http://:52311/cgi-bin/bfgather.exe/actionsite?
We are almost done with a Dashboard that helps check your system to make sure you are following best practices… Hopefully this will help keep your systems in good shape.
understood. Could you please answer the question on the “hidden actions” from the other thread - are you planning to address this issue with the tool?
I really wonder if there should be a disconnected between the content published into the action site and whatever you hold in the database - it’s very useful to have historic deployment information available at all times.
Essentially you should be able to purge the actionsite and keep the historic data in the database.
When you delete an action from the console, the information remains in the database with a flag ‘IsDeleted=True’. All the information is still available but it is not loaded by the console or web reports.
When you delete an action from the console, the information remains in the database with a flag ‘IsDeleted=True’. All the information is still available but it is not loaded by the console or web reports.
This is important to know for people who are accessing the database directly. “Deleting” something from the Console is not the same as actually deleting rows in the database. Because many of our components are designed to pick up just the changes since the last database access, we actually need to have the IsDeleted flags be there as new data. This is especially true for an upcoming future upgrade. So if you’re ever considering actually dropping rows, please make sure you have consulted with our support or professional services people.
As to the question of the hidden actions, I don’t think any of them ever expire. The ones I can think of off the top of my head are the aubscribe/unsubscribe actions, and the user management rights actions, which are good forever.
If you’re worried about Actionsite clutter, in terms of the actual Actionsite that is distributed out to Clients, that gets cleaned out automatically. Any actions that are stopped or expire will automatically be removed from the Actionsite on the next propagation.
thanks for the responses, I suspected that was the case. What I really meant is that purging the actions removes the information from the console - I guess you know where I was going with this - essentially the aim is to keep the actionsite as small as possible while keeping all the historic information available in the console or web reports for auditing purposes.
I’m not keen on manipulating the DB directly, however creating couple of views and/or indexes to access this historic data might be appropriate(?).
We currently have 443 open actions and 3800 clients. We also have 7000 expired and 100 stopped actions. We recently deleted all stopped/expired actions older than 1 year. This did speed up the console a bit.
After double checking the BESPerformance doc, I noticed the BES Server directory was still being scanned by McAfee. Adding this directory to the exclusion list seems to have helped things a little.
A best practices dashboard would be a big help, hope to see that soon.
Hrm. What does “FullSiteURLSize” actually mean? We have been noticing a continued degredation in console speed for quite some time, and haven’t been able to figure out quite why. Maybe this has something to do with it (besides the performance tips, which I already know about)
FullSiteURLSize is the compresesed size of all the administrator’s actions, management rights, property definitions, and everything else that the administrator authorizes. A large number of open actions, actions targeted to lots of computers “by list” or “by specific computer”, very large property definitions, or lots of custom Fixlets contribute to this site.
Generally the size of the fullsiteurlsize doesn’t affect BES Console performance, but if it gets large enough, it can affect console propagation times and also client responsiveness in some cases.
Since many people seem to have questions about “slowness”, I have started some specific discussions on this forum for the different types of performance tuning in BES and what are the factors. If there is a topic that addresses your questions, lets move the discussion to those threads.
Why do you load all of these actions into memory? Wouldn’t it be better to just load a portion of the action into memory and then retrieve the other data when requested? Wouldn’t that improve performance dramatically and decrease the amount of memory used by the Console software?
Most of the action data need to be loaded into memory to populate the columns on the actions tab. We could just have a list of action names and you have to open each one to see the action contents but that would really impair the functionality. The other problem is that you would need to pull the data out of the database at request time and this will cause a significant delay for the user. The console is able to function very well with loading all the data into memory so the cost benefit ratio doesn’t really work out.
Given all this, we did come up with a solution to provide the benefits you are looking for without the penalties for the next version. I don’t think I give specifics on it yet though.
Note that BES 7.0 has moved closer towards the on-demand model of pulling data… basically some of the data will be loaded at startup, but then some of the data will be requested if the user requests it… This hopefully helps balance the tradeoff a little more between load times (should be significantly faster in 7.0), memory usage (should be significantly lower in BES 7.0), and quick access to all the data in the BES Console (sometimes you will see small pauses as previously unloaded data is loaded).