DFM 3.0.2 InsufficientMemory alarm on posixMemory

Unanswered Question
Jan 11th, 2008

After I installed DFM 3.0.2 as part of the LMS Dec 2007 update I have been getting InsufficientMemoryAlarms on my Cat6500's. The alarm is for an instance of memory called "posixMemory". DFM shows 2 instances of "posixMemory" for these switches as well as 2 instances of processor memory and I/O memory. So I have 2 events for each switch (one for each instance of "posixMemory". Is this a bug in DFM? posixMemory sounds like a software data structure so why is DFM managing this? This seems to be something new with DFM 3.0.2.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joe Clarke Fri, 01/11/2008 - 10:32

DFM watches all of the memory pools on the device. What does a walk of . look like? What version of code is running on this switch?

sfenderson Fri, 01/11/2008 - 10:48

Here is the SNMPWalk:

The following is a SNMP walk of device starting from .

SNMP Walk Output



CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolName.1 = STRING: Processor

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolName.3 = STRING: I/O

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolAlternate.1 = INTEGER: 0

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolAlternate.3 = INTEGER: 0

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolValid.1 = INTEGER: true(1)

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolValid.3 = INTEGER: true(1)

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolUsed.1 = Gauge32: 45836344 bytes

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolUsed.3 = Gauge32: 4455344 bytes

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree.1 = Gauge32: 246436956 bytes

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree.3 = Gauge32: 3933264 bytes

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolLargestFree.1 = Gauge32: 241577812 bytes

CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolLargestFree.3 = Gauge32: 3933240 bytes

The switch has a SUP32 and is running 12.2(33)SXH.

Joe Clarke Fri, 01/11/2008 - 11:12

Is this running a modular IOS image? DFM will attempt to query the ENHANCED-MEMPOOL data in that case. Please provide a walk of .

Joe Clarke Fri, 01/11/2008 - 11:40

As you can see from the walk, this is where the posixMemory pools are coming from. The first posixMemory pool shows about 13.1% free, and the second shows about 14.8% free, so those would most likely generate an event in DFM (depending on your threshold). Each pool is tied to a different physical entity. A walk of the entPhysicalTable will tell you what indexes 2001 and 2013 are.

The posixMemory pools reflect the available heap memory for the new POSIX-style (i.e. UNIX-like) processes under modular IOS.

sfenderson Fri, 01/11/2008 - 11:50

These came back as this:

ENTITY-MIB::entPhysicalDescr.2001 = STRING: CPU of Switching Processor 5

ENTITY-MIB::entPhysicalDescr.2013 = STRING: CPU of Routing Processor 5

So I guess I can either change the threshold or unmanage these. Was there a change in DFM 3.0.2 related to these?

Joe Clarke Fri, 01/11/2008 - 11:55

Yes, unmanage, or adjust your threshold. However, if you run out of POSIX heap mem, modular IOS processes will start to fail.

DFM 3.0.2 added more support for modular IOS devices, and these new ENHANCED-MEMPOOL objects were supported.


This Discussion