Bug 536656 (RHQ-984) - optimize our usage of sigar objects
Summary: optimize our usage of sigar objects
Keywords:
Status: CLOSED NEXTRELEASE
Alias: RHQ-984
Product: RHQ Project
Classification: Other
Component: Plugin Container
Version: unspecified
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: ---
Assignee: John Mazzitelli
QA Contact: Corey Welton
URL: http://jira.rhq-project.org/browse/RH...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-15 19:29 UTC by John Mazzitelli
Modified: 2009-03-13 13:38 UTC (History)
0 users

Fixed In Version: 1.2
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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



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