cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1086
Views
1
Helpful
7
Replies

CSCtg23115 - Memory leak in Pool Manager process

Jess13
Level 1
Level 1

What is the Pool manager process responsible for all I can find is "Manager process manages growth and discards requests from dynamic pools at the interrupt level". This does not really clear it up for me, can someone explain this process in terms a beginner can understand? Thank you.

1 Accepted Solution

Accepted Solutions

My understanding…

In classic IOS, physical memory is mapped into a virtual address space and that address space is divided into regions (router# show region) which are used for various purposes such as data structures & heaps, I/O memory, executable code, etc.

Since the amount of memory needed in a region by an IOS config is unknown at compile time (will there be 5 or 500 BGP peers? 5 or 500 subinterfaces?), available memory is managed dynamically at run time by the Pool Manager. Free memory from regions are organized into pools, with the Pool Manager managing malloc/free requests made by IOS processes. If allocated memory is not properly freed (ie, returned to its pool’s free list) by the IOS process or Pool Manager when no longer needed, a memory leak occurs as the IOS process makes repeated memory allocation requests to the Pool Manager without corresponding frees being executed.  (Blocks of free memory in pools can be tracked using the “show memory” exec command.)

It is also my understanding that free memory management via the Pool Manager for IOS processes was retained in IOSd when XE was created, so we should still see it in new releases of IOS-XE, not just in classic IOS from 20 years ago.

Disclaimer: I am long in CSCO

View solution in original post

7 Replies 7

Ruben Cocheno
Spotlight
Spotlight

@Jess13 

Hard to tell.... but Cisco refers to multicast enabled

Tag me to follow up.
Please mark it as Helpful and/or Solution Accepted if that is the case. Thanks for making Engineering easy again.
Connect with me for more on Linkedin https://www.linkedin.com/in/rubencocheno/

Hi, thanks for the answer! Unfortunately, this still does not clear things up as I am having a memory leak issue on some of my switches where the pool manager is using up all the memory. None of the affected switches have multicast routing enabled. 

I need more information for this: 

What platform, what firmwware, what is the uptime?

The platform is a IE-3300-8P2S, the firmware is ie3x00-universalk9.17.13.01.SPA.bin and it had been up for quite a while before I restarted it im not too sure exactly how long but it was probably a couple months at the least. 

Post the complete output to the following command: 

sh version
sh platform resources
sh platform software status conn brief

My understanding…

In classic IOS, physical memory is mapped into a virtual address space and that address space is divided into regions (router# show region) which are used for various purposes such as data structures & heaps, I/O memory, executable code, etc.

Since the amount of memory needed in a region by an IOS config is unknown at compile time (will there be 5 or 500 BGP peers? 5 or 500 subinterfaces?), available memory is managed dynamically at run time by the Pool Manager. Free memory from regions are organized into pools, with the Pool Manager managing malloc/free requests made by IOS processes. If allocated memory is not properly freed (ie, returned to its pool’s free list) by the IOS process or Pool Manager when no longer needed, a memory leak occurs as the IOS process makes repeated memory allocation requests to the Pool Manager without corresponding frees being executed.  (Blocks of free memory in pools can be tracked using the “show memory” exec command.)

It is also my understanding that free memory management via the Pool Manager for IOS processes was retained in IOSd when XE was created, so we should still see it in new releases of IOS-XE, not just in classic IOS from 20 years ago.

Disclaimer: I am long in CSCO

Thank you so much that makes sense to me.