[c-nsp] Free memory with 12.2(25)S

[Rodney Dunn]

I'm not an SNMP person so someone else will have to help
you there.

On Wed, Sep 15, 2004 at 02:05:54AM +0200, Bernhard Schmidt wrote:
> [ I've sent the "same" message before through the gmane.org gateway
>   but it seems to be broken, apologies for the inconvenience when 
>   this message hits the list twice ]
> 
> Hi everyone,
> 
> I've just (for testing, want to play with IPv6 Multicast) upgraded one
> of our access routers from 12.2(18)S4 to 12.2(25)S. Besides an almost
> expected problem (broken encrypted password for an IPv6 BGP peer-group)
> it was pretty flawless, so I took a look into my statistics and almost
> died, because free memory was down to 13MB. The box has 160MB (NPE-300)
> and had 70MB free before the upgrade.
> 
> I'm using cricket for graphing (with genRtrConfig for config generation,
> which btw cannot cope with the new format of sysDescr, but that is no
> showstopper) that queries the SNMP OID 1.3.6.1.4.1.9.9.48.1.1.1.6.1 for
> free memory.
> 
> SNMPv2-SMI::enterprises.9.9.48.1.1.1.6.1 = Gauge32: 13324148
> 
>            [...]  Total(b)   Used(b)   Free(b)  Lowest(b)  Largest(b)
> Processor         80847772  20261464  60586308  13136996   47293344
> 
> so this OID is apparently monitoring the Lowest value. Looking at the
> entire 1.3.6.1.4.1.9.9.48.1.1.1 tree there are Used, Lowest and Largest,
> but no Free.
> 
> I tried to check this with my other boxes, on all of them Free is almost
> equal to Lowest (first big difference, why?). Checking the SNMP values

Lowest should represent the lowest point the free memory ever got to.
Largest is the largest contiguous block you have free.

You can have 50M free with a largest block much smaller than that.

If this is the result immediately after reload it would appear some
process used a lot of transient memory during bootup/initialization
and then freed it back.  Depending on how it's done this could
result in fragmentation (where you have a lot of free but the largest
block is small).

It's optimal to have them pretty close together.  If you monitor
it for a day or so see if the largest gets bigger as we alloc/dealloc
blocks.

If you ever run the box too low on memory you can get in to a condition
where you can never coalesce blocks back together.

As for which to monitor, I suggest monitoring all of them because
they each have a meaning.  

Rodney


> again
> the 1.3.6.1.4.1.9.9.48.1.1.1 tree shows Used, Free and Largest, with
> 1.3.6.1.4.1.9.9.48.1.1.1.6.1 being Free as expected.
> 
> Is this a bug in 12.2(25)S where the wrong column is returned or have
> there been some changes in the software structure that Lowest should be
> monitored now instead of Free?
> 
> Thanks in advance
> Bernhard
> 
> FTR:
> Cisco IOS Software, 7200 Software (C7200-P-M), Version 12.2(25)S
> [...]
> Cisco 7206VXR (NPE300) processor (revision D) with 122880K/40960K bytes
> of memory.
> Processor board ID xxxxxxxxxx
> R7000 CPU at 262Mhz, Implementation 39, Rev 2.1, 256KB L2 Cache
> 6 slot VXR midplane, Version 2.0
> 



> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/