On Fri, Mar 16, 2018 at 4:24 PM, Han Zhou <zhou...@gmail.com> wrote: > > > > On Fri, Mar 16, 2018 at 3:36 PM, Ben Pfaff <b...@ovn.org> wrote: > > > > On Fri, Mar 16, 2018 at 02:31:49PM -0700, Han Zhou wrote: > > > nb_cfg as a mechanism to "ping" OVN control plane is very useful > > > in many ways. However, the current implementation will trigger > > > update notifications flooding in the whole control plane. Each > > > HV updates to SB the nb_cfg number and all these updates are > > > notified to all the other HVs, which is O(n^2). Although updates > > > are batched in fewers notifications than n^2, it still generates > > > significant load on SB DB and also on ovn-controllers. > > > > > > To solve this problem and make the mechanism more useful in large > > > scale producation deployment, this patch separates the per HV > > > nb_cfg data in SB from the Chassis table to a separate table, so > > > that each HV can conditionally monitor and get updates only for > > > its own record. > > > > > > Signed-off-by: Han Zhou <hzh...@ebay.com> > > > > By removing columns this will break upgrades. Do you have another idea? > > Can we just keep the old nb_cfg column in the schema but don't use it, just for ovsdb upgrade to work?
Hi Ben, Here is the test result in ovn-scale-test environment, with 1K sandbox HVs and 10K ports created, and then do the sync test when the system is idle, with command: time ovn-nbctl --wait=hv sync Original result: real 4m52.926s user 0m0.328s sys 0m0.004s With this patch: real 0m11.405s user 0m0.316s sys 0m0.016s As the result is very promising, I would like to submit v2 to keep the old column for upgrading purpose. Do you have any other idea? Thanks, Han _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
