I just replied to the other thread (since I'm running a different version of OVS -2.10.1-) and added ovs-...@openvswitch.org mailing list as well. Oleg, maybe you also want to add the dev list in case they can help on this?
Basically I still observe the continuous memory usage increase by ovs-vswitchd. The growth is almost linear since the process starts. I will try to run the scripts against the dump I collected as well but I don't really have debugging skills to analyze a dump so it may be of little help even if the scripts generate a good output. On jue, feb 28, 2019 at 7:14 PM, Ben Pfaff <b...@ovn.org> wrote: On Tue, Feb 26, 2019 at 01:41:45PM +0400, Oleg Bondarev wrote: Hi, thanks for the scripts, so here's the output for a 24G core dump: https://pastebin.com/hWa3R9Fx there's 271 entries of 4MB - does it seem something we should take a closer look at? I think that this output really just indicates that the script failed. It analyzed a lot of regions but didn't output anything useful. If it had worked properly, it would have told us a lot about data blocks that had been allocated and freed. The next step would have to be to debug the script. It definitely worked for me before, because I have fixed at least 3 or 4 bugs based on it, but it also definitely is a quick hack and not something that I can stand behind. I'm not sure how to debug it at a distance. It has a large comment that describes what it's trying to do. Maybe that would help you, if you want to try to debug it yourself. I guess it's also possible that glibc has changed its malloc implementation; if so, then it would probably be necessary to start over and build a new script.
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
