https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-710 controller <p>A number of devs have observed increasing RAM usage over time, in (at lest) some cases at a very substantial rate.</p> <p>An easy way to replicate this is to run WCBench<span class="error">&#91;1&#93;</span> against ODL for a while, then use the included `stats.py` script to build a graph of used RAM per run (`./stats.py -g ram`, the RAM data will be collected automatically). </p> <p>It's possible that this has to do with logging being enabled. It's also possible that this isn't harmful (unused RAM is wasted RAM). I'm not trying to wave a "serious problem" flag, just to document this behavior and hopefully get someone (maybe me when I have time) to give it some attention.</p> <p><span class="error">&#91;1&#93;</span>: <a href="https://github.com/dfarrell07/wcbench" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/dfarrell07/wcbench</a></p> <p>Operating System: Linux<br/> Platform: PC</p> CONTROLLER-710

Increasing RAM usage over time

Bug Resolved Cannot Reproduce Unassigned Daniel Farrell Wed, 20 Aug 2014 18:51:11 +0000 Mon, 30 Oct 2017 15:41:43 +0000 Tue, 5 May 2015 07:07:29 +0000 Helium mdsal 0 4 <p>Attachment Increasing RAM usage.png has been added with description: Graph that shows increasing RAM usage over time, produced by WCBench</p> <p>Daniel - any reason you think this is openflowplugin rather than the controller?</p> <p>Changed to assign to controller.</p> <p>&gt; Daniel - any reason you think this is openflowplugin rather than the controller?</p> <p>I asked CASP3R about this, he suggested openflowplugin. Honestly not sure.</p> <p>Attachment Screen Shot 2014-08-26 at 7.04.49 PM.png has been added with description: Profiler screen shot</p> <p>Hi Daniel,</p> <p>I hooked up the controller to a profiler and let it run cbench (dropAllPacketsRpc) for an extended period of time. Please see the output in the attached screenshot. You can see the old gen memory slowly growing. Heap is being grabage collected regularly. Also, you can see that there is no major garbage collections happening.</p> <p>At around 1h58 minutes I manually triggered garbage collection from the profiler. You can see a major GC happening (the graph at the bottom of the screenshot), and all memory coming down to pretty much where it was at the beginning of the cbench run.</p> <p>I built the controller from today's master on the openflow plugin project, and used the following jvm parameters for the run: </p> <p>&gt; ./run.sh -Xmx4G -XX:+UseG1GC -XX:MaxPermSize=512m</p> <p>I also set the logging level to ERROR and removed the 'simple forwarding' and 'arp handler' bundles from the distribution before running the test (they interfere with the test - although the loopback is set with dropAllPacketsRpc, these components still get packet_in notifications and I am not sure what they are doing). The controller was running natively on a Mac, cbench was running in a Linux VM on the same Mac as the controller.</p> <p>Another observation is that performance remains stable (i.e. i see no performance degratiation ove rthe course of 2 hours).</p> <p>I'm not seeing this in Helium 0.2.1. Lots of details on this WCBench wiki page<span class="error">&#91;1&#93;</span>.</p> <p><span class="error">&#91;1&#93;</span>: <a href="https://github.com/dfarrell07/wcbench/wiki/Helium-0.2.1-Performance-Results#results-0" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/dfarrell07/wcbench/wiki/Helium-0.2.1-Performance-Results#results-0</a></p> <p>This bug is part of the project to Move all ADSAL associated component bugs to ADSAL</p> Development External issue ID 1591 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02m2v: