[ovs-discuss] ovs-vswitchd memory consumption behavior

Ben Pfaff blp at ovn.org
Mon Mar 4 20:59:24 UTC 2019


Thanks!  I think that 2-3 days should be fine.

On Mon, Mar 04, 2019 at 06:18:38PM +0000, Fernando Casas Schössow wrote:
> I'm running OVS through valgrind since last night and so far so good in terms of performance. Probably because this host is not running network intensive guests.
> 
> I'm running this command from a screen session so I can detach from it without killing valgrind:
> 
> valgrind --leak-check=full --show-leak-kinds=all -v --log-file=ovs-valgrind.log /usr/sbin/ovs-vswitchd --pidfile=/var/run/openvswitch/ovs-vswitchd.pid --mlockall unix:/var/run/openvswitch/db.sock
> 
> Originally Alpine is starting ovs-ovswitchd with --detach and --monitor options but since I'm not running it as a daemon and I don't need the monitor process I thought removing those options was a good idea.
> I'm new to all this but valgrind process RSS size is the same as when I started it (around 140MB). Not sure if this is because ps will show me only valgrind's RSS size and not ovs-vswitchd's or if this is because I started valgrind the wrong way.
> 
> For how long would you suggest I should keep valgrind running? 2-3 days?
> 
> Thanks for looking into this Ben.
> 
> On lun, mar 4, 2019 at 6:22 PM, Ben Pfaff <blp at ovn.org> wrote:
> Running OVS through valgrind is probably going to be unacceptably slow. If it works for you, though, then it will probably tell us the location of the leak. It is possibly a better option to use Address Sanitizer. It is just as good as valgrind for locating memory leaks, but it is much, much faster, possibly fast enough to use in production. On Sun, Mar 03, 2019 at 10:53:17PM +0000, Fernando Casas Schössow wrote:
> After doing some reading I'm wondering if instead of getting a core dump (which I already collected when the process got to around 700MB) it would be better to run OVS through Valgrind and share the log file. What do you think? Any specific OVS or valgrind flags I should use?
> 
> 


More information about the discuss mailing list