(***WARNING***RANT****)
AHA!!! I've been looking for this for ages.
Could you run this again, report the figures you get from net-snmp and the
output of swap -s?
I did it and got (snipped):
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 2625968
UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 1926536
UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000
HOST-RESOURCES-MIB::hrStorageAllocationUnits.3 = INTEGER: 8192 Bytes
HOST-RESOURCES-MIB::hrStorageSize.3 = INTEGER: 635687
total: 2019536k bytes allocated + 380192k reserved = 2399728k used, 2685320k
available
DS> Those two values should probably match, yes.
DS> You don't say what architecture you are running on.
MJ> Oooops! Sorry! In this particular case, I am refering to a Solaris 7
machine.
DS>OK, checking the relevant code:
>DSThe HostRes figure comes from:
swapctl(SC_AINFO, &ainfo);
return ainfo.ani_max;
[host/hr_storage.c:sol_get_swapinfo()]
>DSThe UCD figure comes from:
swapctl(SC_LIST, s)
return sum(s->swt_ent[].ste_pages);
[ucd-snmp/memory_solaris2.c:getTotalSwap()]
DS>That's a gross over-simplification, of course, but it does
DS>show that they're looking at somewhat different things.
DS>I'll now leave it to the Solaris experts to interpret what
DS>these actually measure, and which is correct.
If you look at the swapctl man page (at least for Solaris 8), the API
mentions the SC_LIST.
The pseudocode for the UCD-SNMP-MIB code basically says:
-ask how many swap resources there are
-build a memory structure to contain the swap resource data
-fill it with data
-sum the amount of swap available from each swap entity
-free up memory
>From the API, this appears to be the Right Way of Doing Things and we're
getting the right answer.
I should quibble and say we should be watching out for swap resources in the
process of being deleted, but we are doing snapshots so this probably isn't
the end of the world. This may be more intended to avoid trying to delete
something twice.
The HOST-RESOURCES-MIB does something completely different. It attempts to
use the SC_AINFO systems calls from /usr/include/sys/swap.h that are not
documented in the sysctl API. It is documented in the
/usr/include/vm/anon.h. That documentation points out that swap information
is best recovered through kstat (NOT!) and appears to be more designed for
use by the kernel than by us. Frankly, this code is barking up the wrong
tree. It may have been relevant in older versions of the OS but apparently
Solaris has moved on.
It appears that we should be using the code from UCD-SNMP-MIB in both places
which is a Bad Thing, so I would be tempted to put it downstream somewhere
like agent/mibgroup/kernel_sunos5.c but that includes a whole bunch of stuff
we may not necessarily be interested in (eg. kstat).
This again begs the question of a Hardware Abstraction Layer where we would
store the code for this kind of stuff and call it as needed by both MIBs.
What MAY be happening is that Solaris has had different ways of handling
swap over the years. I'm in the process of building a multi-boot Solaris
development server covering 2.6->11 (open solaris). It should be done by
the end of the week. In the meantime I can wade through the documentation
for the various OSen and see if there's any differences. I'm suspecting
there's been some indiscrete patching going on and the documentation (for
what it's worth) needs to catch up with reality.
I'll submit some patches once I figure out what to do.
Suggestions welcome.
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take action
relying on it. Any communication received in error, or subsequent reply,
should be deleted or destroyed.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
