Description of problem: See the case notes for details but in short, when monitoring several EAP5.0 instances the AS-5 plugin can generate significant CPU utilization, showing up as high, potentially constant, cou utilization in the rhq-agent process. How reproducible: Fairly, continue to add EAP5 instances and the problem occurs fairly linearly. Of course, given system limitations there will always be a bounded number of EAP instances (or nearly any resource, really) that can be managed, but the agent should scale reasonably. Currently, EAP5 scales much less that EAP4. Even when performing well it is expected that the rhq agent will generate CPU utilization spikes when collecting availabity and/or metric information for a large resource population and/or large metric gathering. But it should not generate constant cpu "thrashing" when presented with a reasonable "scale".
removing jon-241 tracker, per RT
f8f501532d2658d814048ecf3879685ddfdff984 Committer: Jay Shaughnessy <jshaughn> 2010-10-28 15:15:58 Perf Work on the AS-5 Plugin to try and reduce avail and metric gathering times. In general trying to reduce interaction with Profile Service. 1) Cache ManagedComponent in ManagedComponentComponent This is the base class for resources managed by a profile service ManagedComponent. It seems that for "runtime" properties getting the prop value returns the live value, so we don't have to re-fetch the ManagedComponent object from the ManagementView. This greatly helps avail checking since RunState is a runtime value. It also helps metric collection if all of the requested metrics are runtime values. 2) Cache whether metrics are runtime or not runtime Instead of figuring out every time whether requested metrics are runtime properties, cache this info to save time. This is a static cache so all instances of the type can share the info. 3) Remove use of ManagedComponentUtils.getManagedComponent() The PS API added ManagementView.getComponent(name, type), which is more efficient. 4) Avoid load() when checking avail for ManagedDeployment components (EAR/WAR) Although it is necessary to re-fetch the ManagedDeployment to get an updated deployment state, a load of the management view is not necessary.
Dropping priority on this as we're approaching the problem from a different angle namely being more selective in the metrics we collect and the rate we collect them: https://bugzilla.redhat.com/show_bug.cgi?id=741331
removing superfluous trackers
closing this, the work is continued in bug 788638