OK, let's do this. Up to the part of getting the process core dump, I'm familiar with (gcore PID). The analysis part of the dump, I will have to learn it...but I hope your scripts will help at least in part.
I restarted OVS last night so it will take a couple of weeks to get to 1.5GB or so, then I will collect the dump and start the analysis. Thanks in advance for helping with this Ben. On dom, feb 17, 2019 at 2:13 AM, Ben Pfaff <[email protected]> wrote: OK, cool. What I usually do for this kind of situation is to start by getting a core dump of the process at the point where it has clearly exceeded the reasonable size limit; in your case, I'd say that's at least a gigabyte or so. The next step is to run some analysis on the heap in the core dump to get a histogram of the most common heap block sizes. Usually, there's one block size that is much more common than the others and the obvious source of the leak. Then you take a look at the actual blocks in question and use their contents along with the size to figure out the source of leaked allocation. Then you fix it (we can help with that part). If you're willing to work on this, then I can dig up some scripts I have for analyzing the heap in a core dump.
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
