Originally documented as item (3) by Dumitru Ceara at https://bugzilla.redhat.com/show_bug.cgi?id=1960042#c4 "We can try to change the way load balancer flows are built. Currently for X routers (or switches) with Y load balancers applied to them we do: - for every router: - for every load balancer: - parse and generate lots of common lb stuff (e.g., VIPs, backends) - generate one logical flow per VIP. I think we can save quite a lot of CPU by changing this to: - for every load balancer: - parse and generate lots of common lb stuff (e.g., VIPs, backends) - for every router: - generate one logical flow per VIP."
Posted upstream: http://patchwork.ozlabs.org/project/ovn/list/?series=249654&archive=both&state=*
v6 accepted upstream on July 5th: http://patchwork.ozlabs.org/project/ovn/list/?series=252015&state=* Follow up patch to reduce ovn-northd loop times further: http://patchwork.ozlabs.org/project/ovn/list/?series=252096&state=*
v2 of follow up patch to reduce ovn-northd loop times further: http://patchwork.ozlabs.org/project/ovn/list/?series=253248&state=*
v3 of follow up patch to reduce ovn-northd loop times further: http://patchwork.ozlabs.org/project/ovn/list/?series=253875&state=*
All patches should be in ovn21.09-21.09.0-9.el8fdp and later.
according to the patch ,I test it as below: I create 100 LRs, and 1 LB with 1K vips.then sync, on the old version, it took about 30s to sync,but on the fixed version, only 5s. topo: vm0---------s0-----------r1-------s1----------vm1 | rn | sn | vmn (n=100) #sw public ovn-nbctl set NB_GLOBAL . options:northd_probe_interval=180000 ovn-nbctl set connection . inactivity_probe=180000 ovs-vsctl set open . external_ids:ovn-openflow-probe-interval=180 ovs-vsctl set open . external_ids:ovn-remote-probe-interval=180000 ovn-sbctl set connection . inactivity_probe=180000 ovn-nbctl ls-add public ovn-nbctl lb-add lb0 100.10.1.2:880 172.16.1.2:9000 for i in `seq 40`;do for j in `seq 25`;do ovn-nbctl lb-add lb0 192.$i.$j.1:80 172.16.1.3:9000 ------------create LB with 1K vips done done # r1 i=1 for m in `seq 0 9`;do for n in `seq 1 99`;do ovn-nbctl lr-add r${i} ovn-nbctl lrp-add r${i} r${i}_public 00:de:ad:ff:$m:$n 172.16.$m.$n/16 ovn-nbctl lrp-add r${i} r${i}_s${i} 00:de:ad:fe:$m:$n 173.$m.$n.1/24 ovn-nbctl lr-nat-add r${i} dnat_and_snat 172.16.${m}.$((n+100)) 173.$m.$n.2 ovn-nbctl lrp-set-gateway-chassis r${i}_public hv1 # s1 ovn-nbctl ls-add s${i} ovn-nbctl lr-lb-add s${i} lb0 # s1 - r1 ovn-nbctl lsp-add s${i} s${i}_r${i} ovn-nbctl lsp-set-type s${i}_r${i} router ovn-nbctl lsp-set-addresses s${i}_r${i} "00:de:ad:fe:$m:$n 173.$m.$n.1" ovn-nbctl lsp-set-options s${i}_r${i} router-port=r${i}_s${i} # s1 - vm1 ovn-nbctl lsp-add s$i vm$i ovn-nbctl lsp-set-addresses vm$i "00:de:ad:01:$m:$n 173.$m.$n.2" ovn-nbctl lrp-add r$i r${i}_public 40:44:00:00:$m:$n 172.16.$m.$n/16 ovn-nbctl lsp-add public public_r${i} ovn-nbctl lsp-set-type public_r${i} router ovn-nbctl lsp-set-addresses public_r${i} router ovn-nbctl lsp-set-options public_r${i} router-port=r${i}_public nat-addresses=router let i++ if [ $i -gt 100 ];then break; fi done if [ $i -gt 100 ];then break; fi done ovn-nbctl lsp-add public ln_p1 ovn-nbctl lsp-set-addresses ln_p1 unknown ovn-nbctl lsp-set-type ln_p1 localnet ovn-nbctl lsp-set-options ln_p1 network_name=nattest ovn-nbctl lr-nat-del r1 dnat_and_snat 172.16.0.101 ovn-nbctl lr-nat-add r1 dnat_and_snat 172.16.0.101 173.0.1.2 vm1 00:00:00:01:02:03 then, do "ovn-nbctl --wait=sb sync" ovn-2021-21.06.0-29.el8fdp.x86_64 ovn-2021-host-21.06.0-29.el8fdp.x86_64 ovn-2021-central-21.06.0-29.el8fdp.x86_64 :: [ 07:06:37 ] :: [ BEGIN ] :: Running 'ovn-nbctl --wait=sb sync' :: [ 07:07:11 ] :: [ PASS ] :: Command 'ovn-nbctl --wait=sb sync' (Expected 0, got 0) # rpm -qa|grep ovn ovn-2021-host-21.09.0-12.el8fdp.x86_64 ovn-2021-21.09.0-12.el8fdp.x86_64 ovn-2021-central-21.09.0-12.el8fdp.x86_64 :: [ 06:16:16 ] :: [ BEGIN ] :: Running 'ovn-nbctl --wait=sb sync' :: [ 06:16:21 ] :: [ PASS ] :: Command 'ovn-nbctl --wait=sb sync' (Expected 0, got 0) set verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (ovn bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:5059