We've now traced our memory leak to a rogue custom availabillty chart. The chart was showing availabiility over last 30 days for 8 nodes. It appears the chart was somehow corrupt as creating a new chart with the same data didn't trigger the memory leak. We found this by isolating different elements of a view we'd been working on and loading each one in turn until the memory started increasing significantly.
Interestingly, closing the page showing the chart didn't release the memory back that the information service had grabbed. Only way to do this was to kill the information service v3 and let it respawn.
Weirdly, after making a custom chart, I have the same problem. It spiked at 97%
I want to end the service and then restart and see it that resolves it.
Urgh - why does s**t have to be so complex sometimes. I only want a b****y chart and it's gone insane and taking 14gb up.
We have fixed a couple of memory leaks since 12.0. The best bet is to install the latest Service Release and Hot Fixes. If the issue continues, it's time to open a Support case and we'll dig in with you.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.