nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ICX8200 memory increasing by 1% every 6-12 hours

Sydney_N

This may be related to an existing error found in the 1010b release notes: "memory increases over a long period of time."

The memory utilization for one of the 8200s we have installed (we have 2 others that are not experiencing this issue) increases slowly, typically by 1% every 6-12 hours, and continues to climb until I reload the switch. After reloading, the memory goes back to the normal 30%, then continues to climb again. This same issue happened with this switch when the switch was running code 1010, upgrading to 1010a resolved it, but it started happening again right after upgrading to 1010b. I compared the "show memory tasks" to another 8200 on 1010b and it appears to be using less memory than the 8200 that is not having memory issues.

In the release notes, it states it is related to syslogging, so I tried disabling informational and notification logs, plus reducing the dynamic log buffer lines, but this didn't make a difference.

Also in the release notes, it states there is no fix or workaround, is there really no fix?

Find more posts tagged with

Accepted answers

BenBeck

The only way to know for certain what is causing the leak is to debug it and have support decode the samples. If you would like to do this, please gather the following and open a support case:

show mem (note baseline mem usage)

debug mem-leak on (issue this one time to turn on debug tracking)

Issue the following commands on an interval (ensuring memory rises 3+% between each instance of output):

show mem

show memory mem-leak ref-cnt

show memory mem-leak resource

The samples with high ref-cnt are likely the source of the leak. We can decode those and determine if it is a known issue or something new. Hope this helps!

All comments

BenBeck

The only way to know for certain what is causing the leak is to debug it and have support decode the samples. If you would like to do this, please gather the following and open a support case:

show mem (note baseline mem usage)

debug mem-leak on (issue this one time to turn on debug tracking)

Issue the following commands on an interval (ensuring memory rises 3+% between each instance of output):

show mem

show memory mem-leak ref-cnt

show memory mem-leak resource

The samples with high ref-cnt are likely the source of the leak. We can decode those and determine if it is a known issue or something new. Hope this helps!

Mayank

Hi Sydney_N

Adding to the post since the mem utilzation increase every 6-12 hours, you can take the below outputs "one in morning 6AM " and "one in Evening 6PM " that is mainly in a gap of 12 hours .

Capture below in morning :

show tech
show memory (note baseline mem usage)
dm mem-leak on (issue this one time to turn on debug tracking)
dm mem-leak show resource
dm mem-leak show ref-cnt
show cpu tasks

Capture below outputs once on evening:

show tech
show memory
dm mem-leak show resource
dm mem-leak show ref-cnt
show cpu tasks

Then in Evening please turn off the mem-leak counters with "dm mem-leak off".

After collecting the above output please send us on case.

If the case is not yet created you can log a ticket with the below link so that we will help you further

https://support.ruckuswireless.com/contact-us

I hope this information helps you

Thanks

Sydney_N

Sounds good, thank you. I will open a case with that information.

Mayank

Hi Sydney_N ,

This is Acknowledged .