Reboot interval on a busy ASA 5505

[lcaruso]

I'd like to know what the experts advise on reboot intervals for busy 5505s. I mean, even the best garbage collection routines are eventually challenged and memory is never perfectly consoliatded like it is after a reboot.

I have a client with 5505 which is running 8.3 and is currently using about 200MB out of 512MB and has not been rebooted for 120 days. This unit handles a high, sustanied rate of traffic. My incliniation is this box should be rebooted.

What do you advise?

[Kureli Sankar · Accepted solution]

Some processes take up certain type of memory that they will not release either due to a software defect or due to the nature of the memory that they are programmed to use.  In those cases only a reload will release the memory.

If on this ASA5505 memory seems to be leaking over time, whether slowly or rapidly, it needs to be looked at as to which bin size memory and which process is taking up a lot of memory. Opening a TAC case is the best course of action.

Although, it is not required to reboot the unit once in 3 months or 6 months, I do believe a reload at least once a year is good to do.

-KS

[lcaruso]

Thanks. Are the commands to check for memory leaks documented for mere mortals?

[Kureli Sankar · Accepted solution]

They are now .

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/s4.html#wp1488170

1) Get the output of 'show mem detail' to see the current amount of free memory.
2) Then, from the output of 'show mem detail', look at the second  section (scroll down) "----- allocated memory statistics -----". This will show the  different memory fragment sizes, and how much total memory on the  firewall is used up by fragments of a particular size:

From this output, examine the total number of bytes allocated (the  third column) and see which fragment size is using the most memory. If  the free memory on the box reduces over time, take this output several  times in a day and see which fragment size is using more and more  memory.

3) Once you've found the fragment size that is eating the memory,  issue a 'show mem binsize xxxx' where xxxx is the particular fragment  size.

The above "sh mem binsize xxx" will show you processes that are using that particular bin.  We need to decode that hex value to a valid process name. - Need to open a case with TAC for this.

-KS

[lcaruso]

Wonderful--thank you!