We are also seeing this in bionic with rocky neutron-openvswitch-agents. We haven't really found any pattern in when it occurs, but even after emptying out a compute node with live migrations and rebooting it, we will keep seeing it. Amount of traffic doesn't seem to be related.
What we are seeing are an increasing number of handler threads using 100% cpu which in our setup can mean several 1000% in total being used by ovs-vswitchd. While investigating we found that the handler threads seemed to spend quite a lot of time in native_queued_spin_lock_slowpath, making us believe there might be too many threads running competing for the same locks so we tried lowering other_config:n-handler-threads, which actually seemed to fix the issue, but it seems to have just been a temporary fix as we still see the issue and in fact may just be that the modification of the other_config:n-handler-threads variable slays the handlers that have been stuck in 100% CPU and spun up new fresh ones. I find it strange however that a rebooted node doesn't see the same though which makes me think there is something going on during startup of either OVS or openstack-neutron-agent that in some circumstances causes this. Investigation is on-going, just wanted to share our observations so far. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1827264 Title: ovs-vswitchd thread consuming 100% CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1827264/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
