Bug 536656 - (RHQ-984) optimize our usage of sigar objects
optimize our usage of sigar objects
Product: RHQ Project
Classification: Other
Component: Plugin Container (Show other bugs)
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: John Mazzitelli
Corey Welton
: Improvement
Depends On:
  Show dependency treegraph
Reported: 2008-10-15 15:29 EDT by John Mazzitelli
Modified: 2009-03-13 09:38 EDT (History)
0 users

See Also:
Fixed In Version: 1.2
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Mazzitelli 2008-10-15 15:29:00 EDT
We should go through all the places we use SIGAR and optimize the places that create and/or destroy sigar objects.

From hyperic forums:


"new Sigar() isn't expensive, but can be helpful to keep it long-lived. For example, the cpu % metrics use the delta of the last time sampled where the previous sample is stored in a hash table within the underlying sigar_t structure. Similar for a few others such the disk service time metric.

SigarProxyCache is most helpful for methods such as Sigar.getProc{State,Args,Env} where they might be invoked N number of times within a short time period. HQ plugins using PTQL for auto-discovery was the original use-case where having this cache will avoid duplicating the system calls, parsing, memory allocations, etc., for a given auto-discovery scan.

The system metrics are collected when you call a method on the Sigar object, such as sigar.getMem(). The Mem object instance returned is not updated until the next time sigar.getMem() is invoked, so the collection period is entirely up to you. SigarProxyCache.getMem() however, would return the in-memory cached value of the Mem object, only calling into the system sigar.getMem() when the cache has expired."
Comment 1 Greg Hinkle 2008-11-19 20:48:52 EST
This can be a performance impact on servers that have large core counts or where sigar has to work harder to find the proper counts.
Comment 2 Greg Hinkle 2008-11-20 15:11:48 EST
Fixed by using SigarProxyCache... caching data for only 1 second, but should help with some of the tight loop accesses. Otherwise the main value is the cpuinfo not having to be reloaded for each new Sigar().
Comment 3 John Mazzitelli 2008-11-20 16:11:32 EST
this broke the ability to turn on/off native system on the fly at runtime.

Start the agent with --nonative
Type "native --os".
Then "native --enable"
Then "native --os" again.  The output should be different (because the values are different coming from Sigar than from Java).
Comment 4 John Mazzitelli 2008-11-20 16:40:33 EST
svn rev2050 fixes it
Comment 5 John Mazzitelli 2008-11-20 16:41:11 EST
revs 2048 and 2050 implement this
Comment 6 Corey Welton 2009-02-04 14:19:20 EST
QA Verified, the native --enable/--disable and all associated functionality works correctly.
Comment 7 Red Hat Bugzilla 2009-11-10 16:21:00 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-984
This bug relates to RHQ-1750

Note You need to log in before you can comment on or make changes to this bug.