Here's the output you requested: swap -s: total: 2653088k bytes allocated + 37416k reserved = 2690504k used, 2899264k available
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 4003952 UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 1528520 UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000 HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: Swap Space HOST-RESOURCES-MIB::hrStorageAllocationUnits.3 = INTEGER: 8192 Bytes HOST-RESOURCES-MIB::hrStorageSize.3 = INTEGER: 698726 So that I understand it, the Host-Resources MIB contains the incorrect values. So, if an NMS (like SolarWinds), it is going to get values that do not what is really on the system. I am still confused as to why the numbers do not match. Assuming the values that swap -s are correct, then there is 2690504k + 2899264k = 5592344k (5726560256 bytes) of swap. However, from the Host resources MIB, 698726 * 8192 = 5723963392 bytes, which does match. They are close, so I could be tempted to simply say there is 5.7 Gb on this system What units is memTotalSwap? I am now totally consfused as to where this value is coming from. Regards, Jim Mohr >> -----Ursprüngliche Nachricht----- >> Von: Bruce Shaw [mailto:[EMAIL PROTECTED] >> Gesendet: Donnerstag, 23. Juni 2005 21:35 >> An: Mohr James >> Cc: [email protected] >> Betreff: RE: UCD versus Host Resources Values for Swap >> >> >> (***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 show that >> DS>they're looking at somewhat different things. I'll now >> leave it to >> DS>the Solaris experts to interpret what these actually measure, and >> DS>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_idt77&alloc_id492&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
