I am working on how to reproduce it, but not yet have clue.
Some finding when the memory usage is large:
1) Usually the flow once reached the limit, example as below
# ovs-appctl upcall/show
flows : (current 100) (avg 104) (max 206205) (limit 199000)
dump duration : 1ms
ufid enabled : true
12: (keys 100)
2) There are attacks from VM port, like syn flood with different source TCP
3) There are lots of detailed flow in data path. Like including detailed TCP
src and dst port, even I do not specify TCP info in my openflow rule. I can not
understand this. Any idea?
ovs-appctl dpif/dump-flows br0
If there is no memory leak, and caused by memory fragment, I believe we can use
dpdk memory pool instead alloc()/free() here and there.
From: William Tu [mailto:u9012...@gmail.com]
Sent: Saturday, February 03, 2018 1:46 AM
To: Ben Pfaff
Cc: 王志克; email@example.com
Subject: Re: [ovs-dev][PATCH] memory: kill ovs-vswitchd under super
On Fri, Feb 2, 2018 at 7:48 AM, Ben Pfaff <b...@ovn.org> wrote:
> On Fri, Feb 02, 2018 at 12:37:58PM +0000, 王志克 wrote:
>> I also found that if once theres are lots of flows, the memory (RSS) usage
>> of OVS process would be quite high, 2~3GB. Even then the flows disappear
>> later, the memory still keeps.
Are you able to reproduce the issue?
There might be a memory leak around cls_rule, miniflow/minimatch allocation.
Can you share more information about your setup?
>> I am not sure how many people notices this, but if indeed OVS has such
>> defect, I guess this should be critical blocker.
> This is normal behavior of the C library malloc implementation.
dev mailing list