cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
435
Views
0
Helpful
8
Replies

Mallocfail due to a RIP Process - I think

andrewmorris
Level 1
Level 1

Hi Guys,

Check this out and tell me if you agree with me that the reason for the mallocfail was due to a RIP process.

I am not certain exactly what about RIP could have caused this and perhaps one of you could please assist.

Many Thanks

Andrew Morris

Mar 17 14:16:53.611: %SYS-2-MALLOCFAIL: Memory allocation of 672 bytes failed from 0x603BDA30, pool Processor, alignment 0

-Process= "RIP Router", ipl= 4, pid= 77

-Traceback= 60408658 6040A358 603BDA38 603BDEB4 603BE450 606F456C 606F4A90 606F4BDC 60556E80 606F9A9C 606FA11C 603FEE04 603FEDF0

Mar 17 14:18:47.143: %SYS-2-MALLOCFAIL: Memory allocation of 672 bytes failed from 0x603BDA30, pool Processor, alignment 0

-Process= "RIP Router", ipl= 4, pid= 77

-Traceback= 60408658 6040A358 603BDA38 603BDEB4 603BE450 606F456C 606F4A90 606F4BDC 60556E80 606F9A9C 606FA11C 603FEE04 603FEDF0

Mar 17 14:39:23.848: %SYS-2-MALLOCFAIL: Memory allocation of 672 bytes failed from 0x603BDA30, pool Processor, alignment 0

-Process= "RIP Router", ipl= 4, pid= 77

-Traceback= 60408658 6040A358 603BDA38 603BDF00 603BE450 606F456C 606F4A90 606F4BDC 60556E80 606F9A9C 606FA11C 603FEE04 603FEDF0

8 Replies 8

ruwhite
Level 7
Level 7

RIP certainly asked for the memory, but that doesn't mean RIP is the cultprit, it could be the victim. What you need to do is to look at show mem and check to see if memory is fragmented, or you are just out of memory. The next thing to look at would be to see which processes are holding the most memory. If RIP happens to be holding the most memory, or a _lot_ more memory than other processes, then you might conclude that RIP is a victim of it's own memory consumption.

Once you've figured out which process is consuming the memory, then you need to look at why it's consuming the memory. For instance, if RIP is holding a lot of memory, then is to hold routes (which would be perfectly natural)? Perhaps the router is just overloaded.... Or maybe not. It's hard to tell without analyzing the output, and working through the network conditions this router lives in.

:-)

Russ.W

Thanks Russ,

That gives me something to go on.

When you start narrowing things down some (which process is holding memory), and need/want some help figuring out the next step (how to determine if that process should be holding that much memory), feel free to post those questions here, or email me with them. mallocfials can either be very easy to solve, or very very hard, mostly they fall into the very hard category, in my experience....

:-)

Russ.W

Hi There Russ,

Thanks again, and following your advice the only process which I saw holding more memory that has been allocated is this process:

Now I'm note certain what this is, but it seems like a default option to me. I am not certain what I should be comparing it to though.

PID TTY Allocated Freed Holding Getbufs Retbufs Process

0 0 92004 1848 5252608 0 0 *Init*

Thanks

Andrew

*Init* is a "catchall" for processes that take up memory before the memory manager starts. It's not holding enough memory to worry about here, I don't think.... You're not really concerned with the allocated vs holding values, just the holding value. What are the top two or three processes in the holding column?

:-)

Russ.W

Hehe, Russ, here it comes, the entire sh proc mem, well I tried to but it was too much so just the processes in question

There's nothing out of the ordinary here that I can see apart from "IP Input" and "RIP Router" processes and even these aren't holding unneccesary amounts of memory.

I think I am just going to put it down to a major "blip" on the network when RIP either was told to or decided to dominate the world.

Thanks again

Andrew

28 0 563902936 10448 1198260 22241784 6656 IP Input

77 0 3113915760 691468432 215020 3950714628 94848 RIP Router

78 0 879408 2922956468 6924 429408 26624 RIP Send

Can you look at a show ip route summ, and see if the RIP number there looks close to the RIP number here? Second, what are the largest, lowest, and free when you do a show proc mem? It looks like you got a ton of routes at once, or some other process sucked up a ton of memory at one point, and then released it. But RIP does have what looks like a lot of malloc's and free's, so it's hard to be precise at the moment...

(Oh, not that it's ever easy to be precise with a malloc fail problem.) :-)

:-)

Russ

Thanks Russ, the problem has not reoccurred since so I have put this to bed.

Thanks for all your help

Regards

Andrew