Memory usage on ASA 8.03

Unanswered Question
Jan 10th, 2008

Hi all,

I have a big problema of dayly increasing memory usage on asa 5510 8.03.

I turned off statistics and threat-management saving 50MB but the memory increases of about 10MB/day.

Once already crashed.

Please let me know if you can help me.

Thanks

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (4 ratings)
Loading.
ebreniz Wed, 01/16/2008 - 15:31

It is normal to see an increase however we need to see as well how much did it increased and what is the current value that you see and compare it to what you previously had.

To trace which process caused this memory problem we'll have to:

-Do a show mem detail

-In the allocated memory statistics part check which are the 3 fragment size

that have the highest total, look for uncommonly big numbers in comparison

to the others in the total column

-Do a show mem binsize of the 3 fragment size

-Send me the display of all of this including the mem detail, all this has

to be done when the memory is having this overflow problem (The memory

allocation errors should have been caused because of this)

With this we can trace the process that's eating up memory.

the bug we might be hitting CSCsk77613, also CSCsk64111 could be presenting which is

also related to WebVPN, if this is the case upgrading to version 8.03 should fix this.

cisco24x7 Wed, 01/16/2008 - 15:45

he is already running version 8.0(3). How

is that going to fix the problem?

CCIE Security

interknox Sun, 01/20/2008 - 14:12

I too am having the same issues with 8.0(3). My memory usage has doubled since coming from 7.x (which I figured was okay) but every day, there's another 1mb or so that is added on. It's climbing without any additional input from me...does this on its own.

This is on a 5505. I've got 5 - 5510's that I'm getting ready to upgrade to 8.0(3), so we'll see how that goes.

JORGE RODRIGUEZ Sun, 01/20/2008 - 14:26

Guys, I would recommend you open a TAC case, not to scare you off from 8.03 but I have already read some bug reports on this code and there are stil some bugs opened , Im not saying this memory thing is a bug but to be sure I would definately call TAC, specially when 1st poster had a crash.., these things need to be communicated to TAC, post whatever results you get form Cisco so the forum community can learn of it too.

Rgds

Jorge

interknox Sun, 01/20/2008 - 18:47

I have opened a TAC case.

On a side note, what is the "average" memory/cpu usage for a 5505, that is running a dynamic DSL connection and ~2 or 3 people in the office using the "average" internet usage (email, light web usage)?

Right now I'm running at 163mb memory usage and ~16% CPU usage.

I realize this is an open ended question as it varies...

JORGE RODRIGUEZ Sun, 01/20/2008 - 19:51

I have a asa5505 in a lab connected to non-production cisco equipment and only myself testing but nothing realy going on in terms of heavy traffic other than basic snmp traps, ntp etc.. is currently using 118MB out of 265 memory usage at %14 cpu utilization. with code 8.0(3).

interknox Sun, 01/20/2008 - 19:57

Wow. That's a huge difference from my memory usage @ 163mb and I'm not doing much more than you are with my ASA.

mhcraig Mon, 01/21/2008 - 06:42

Add me to the list ;)

Just chiming in here as well... I have a 515e pair and upgraded from 7.x to 8.03. After turning on basic threat detection the memory usage shot up from around 60MB to 115MB and stayed there. I since have shut off statistics and threat-management as you have which has actually dropped the memory consumption to less than what is was with 7.x but we'll see if that changes. I haven't had it running with 8.03 long enough to monitor the consumption over time. I plan to do that for a week before I open a TAC case.

One unusual thing that happens - and if someone has experienced this since upgrading to 8.03 please let me know - is that the CPU is similar to the usage I saw with 7.x, *except* when there are traffic spikes. Example, normally the internet-facing interface chugs along at around 10-15 mbit/sec and spikes to 30 mbit/sec at times. With 7.x the CPU usage would be around 30-35%. Now with 8.03 that same traffic spike (usually due to SMTP traffic) causes the PIX to use upwards of 75% of the processor!

I have a list of changes to the config using source control and the changes *seem* minimal and were all put in place automatically during the upgrade.

I'll keep an eye on this thread and if someone opens a case before I do please post the conclusion.

Thanks,

Hutch

husycisco Mon, 01/21/2008 - 07:58

Hi All

Make sure logging buffer is disabled. Buffer keeps some logs in memory for days for viewing charts like last x days VPN connections and so on.

Type clear logging to clear the buffer and no logging buffered to disable it

Regards

manjesin Mon, 01/21/2008 - 09:20

There is an command "memory tracking enable" introduce after 8.0.2.36 software which can help narrowdown the memory leak issue on ASA

Here is example how we can narrowdown the issue on 8.0.2.36 or later images.

1)Collect the "sh mem details" output over the period of time and find largest fragment size which is increasing and collect sh mem binsize (fragment size).

2)Enable "memory tracking enable" to allow the appliance to automatically track leaked memory

3)After enabling the command, wait until you are sure memory has leaked,

and then issue the command show memory tracking to see what process has

leaked memory (Only functions that have acquired memory since the memory

tracking feature was enabled will appear)

4)Need to look for the largest change

Example :-

ciscoasa(config)# memory track enaable

ciscoasa# show mem tra add

memory tracking by caller:

17 bytes from 1 allocates by 0x080c50c2

37 bytes from 1 allocates by 0x080c50f6

57 bytes from 1 allocates by 0x080c5125

20481 bytes from 1 allocates by 0x080c5154

memory tracking by address:

37 byte region @ 0xa893ae80 allocated by 0x080c50f6

57 byte region @ 0xa893aed0 allocated by 0x080c5125

20481 byte region @ 0xa8d7cc50 allocated by 0x080c5154

17 byte region @ 0xa8a6f370 allocated by 0x080c50c2

5) Now we would take the memory dump for the highest change functions which is x.x.x.x.xed0

ciscoasa# show mem tra dump 0xa893aed0

6)This output will give you threads which can be easily searched to relate the process that was responsible for the memory leak

memtrk_utest_alloc+117 or webvpn_ci_memory_chain

If u found this useful pls rate so that other can take benefit of these steps ..

Regards

Actions

This Discussion