Thanks Jesse, I have a NAT firewall which logs something like this every second - OVS is processing ~400.000 packets/s - and I'm having issues with response times or even timeouts when load > 96%. Is there anything I can do about the latency/CPU usage, other than not running OVS on the NAT firewalls ?
Thanks. 2013-04-16T09:51:27Z|8146123|timeval|WARN|Dropped 19 log messages in last 57 seconds (most recently, 8 seconds ago) due to excessive rate 2013-04-16T09:51:27Z|8146124|timeval|WARN|64 ms poll interval (4 ms user, 60 ms system) is over 22 times the weighted mean interval 3 ms (3135277762 samples) 2013-04-16T09:51:27Z|8146125|timeval|WARN|context switches: 0 voluntary, 16 involuntary 2013-04-16T09:51:27Z|8146126|coverage|INFO|Dropped 19 log messages in last 57 seconds (most recently, 8 seconds ago) due to excessive rate 2013-04-16T09:51:27Z|8146127|coverage|INFO|Skipping details of duplicate event coverage for hash=fc7a4baa in epoch 3135277762 2013-04-16T09:51:27Z|8146128|poll_loop|WARN|wakeup due to [POLLIN] on fd 18 (unknown anon_inode:[eventpoll]) at ../lib/dpif-linux.c:1183 (96% CPU usage) 2013-04-16T09:51:28Z|8146129|poll_loop|WARN|Dropped 325 log messages in last 1 seconds (most recently, 1 seconds ago) due to excessive rate 2013-04-16T09:51:28Z|8146130|poll_loop|WARN|wakeup due to [POLLIN] on fd 18 (unknown anon_inode:[eventpoll]) at ../lib/dpif-linux.c:1183 (96% CPU usage) 2013-04-16T09:51:28Z|8146131|poll_loop|WARN|wakeup due to [POLLIN] on fd 18 (unknown anon_inode:[eventpoll]) at ../lib/dpif-linux.c:1183 (96% CPU usage) 2013-04-16T09:51:29Z|8146132|poll_loop|WARN|Dropped 455 log messages in last 1 seconds (most recently, 1 seconds ago) due to excessive rate 2013-04-16T09:51:29Z|8146133|poll_loop|WARN|wakeup due to [POLLIN] on fd 18 (unknown anon_inode:[eventpoll]) at ../lib/dpif-linux.c:1183 (96% CPU usage) 2013-04-16T09:51:29Z|8146134|poll_loop|WARN|wakeup due to [POLLIN] on fd 18 (unknown anon_inode:[eventpoll]) at ../lib/dpif-linux.c:1183 (96% CPU usage) 2013-04-16T09:51:30Z|8146135|poll_loop|WARN|Dropped 364 log messages in last 1 seconds (most recently, 1 seconds ago) due to excessive rate 2013-04-16T09:51:30Z|8146136|poll_loop|WARN|wakeup due to [POLLIN] on fd 18 (unknown anon_inode:[eventpoll]) at ../lib/dpif-linux.c:1183 (97% CPU usage) 2013-04-16T09:51:30Z|8146137|poll_loop|WARN|wakeup due to [POLLIN] on fd 18 (unknown anon_inode:[eventpoll]) at ../lib/dpif-linux.c:1183 (97% CPU usage) 2013-04-16T09:51:31Z|8146138|poll_loop|WARN|Dropped 419 log messages in last 1 seconds (most recently, 1 seconds ago) due to excessive rate On 08/04/2013, at 23.27.04, Jesse Gross <je...@nicira.com> wrote: > On Mon, Apr 8, 2013 at 2:13 PM, Kristoffer Egefelt <kristof...@itoc.dk> wrote: >> OK thanks - however ovs-dpctl show: >> >> lookups: hit:142051685241 missed:16517079493 lost:215200 >> flows: 1544 >> >> with cpu utilization around 80% and ~250.000 p/s >> >> (I hope this is the correct way to see amount of current flows) >> >> If SSH (through OVS) have noticeable delay I would think that all traffic >> going through OVS would experience this delay ? > > Yes and no. OVS tries harder to keep high bandwidth flows in the > kernel (which would not see this delay). SSH is low bandwidth and > storage would likely be high bandwidth. Storage traffic by itself is > not likely to cause stress on OVS but if OVS is already stressed due > to other traffic then you are in somewhat more dangerous territory. > _______________________________________________ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
