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.
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
Committer: Jay Shaughnessy <firstname.lastname@example.org> 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
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