Bug 536656 (RHQ-984)

Summary: optimize our usage of sigar objects
Product: [Other] RHQ Project Reporter: John Mazzitelli <mazz>
Component: Plugin ContainerAssignee: John Mazzitelli <mazz>
Status: CLOSED NEXTRELEASE QA Contact: Corey Welton <cwelton>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Improvement
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-984
Whiteboard:
Fixed In Version: 1.2 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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

From hyperic forums:

http://forums.hyperic.com/jiveforums/thread.jspa?threadID=6280

"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-20 01:48:52 UTC
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 20:11:48 UTC
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 21:11:32 UTC
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 21:40:33 UTC
svn rev2050 fixes it

Comment 5 John Mazzitelli 2008-11-20 21:41:11 UTC
revs 2048 and 2050 implement this

Comment 6 Corey Welton 2009-02-04 19:19:20 UTC
QA Verified, the native --enable/--disable and all associated functionality works correctly.


Comment 7 Red Hat Bugzilla 2009-11-10 21:21:00 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-984
This bug relates to RHQ-1750