Hi Andy,
On 17.03.2017 02:28, Andy Zhou wrote:
On Thu, Mar 16, 2017 at 1:52 PM, Ben Pfaff <b...@ovn.org> wrote:
On Thu, Mar 16, 2017 at 11:38:19PM +0500, Valentine Sinitsyn wrote:
On 16.03.2017 20:56, Ben Pfaff wrote:
On Tue, Mar 14, 2017 at 07:08:54PM +0500, Valentine Sinitsyn wrote:
Recently, I was evaluating a multi-threaded OVSDB/ovn-northd design, and
came across the patchset [1].
Looks like this RFC patchset was received well, but never completed. What's
the reason? No real performance benefits, lack of interest, other
high-priority tasks or whatever?
It's kind of a combination of those. Andy got preempted by other
higher-priority work, plus it's unclear whether threading ovsdb-server
solves an important problem at this time. I'm currently working on
adding clustering support to OVSDB, which ought to allow scaling out
reads, which are most of the OVN workload, so that might solve the same
problem in a different way.
This sounds promising. Are you planning something Mongo-like, that is, one
server writes should be directed to, and all servers serving reads?
That's essentially the planned approach. This should allow better
scaling out reads. Half an hour isn't really acceptable and OVN should
aim to do much better than that.
In our tests, it takes about half an hour (and a few hundred
reconnects) to send an initial snapshot of a large southbound database
to 1000+ OVN 2.7 controllers. This makes disaster recovery plan a
pain. Should we expect things to get better here (we can probably
contribute to this, if feasible)?
I'd expect that the clustered database design should scale pretty well
for reads, which are most of the OVN workload. I'll have to have
something actually working before we can test and tune it, though.
As for multi-threaded OVSDB, the latest patch series I found in Andy's fork
segfaults just after startup, so we can't even do a quick test to check if
it makes things better for us or not.
I don't know whether Andy thought it was ready for testing.
It was work-in-progress, not ready for testing. I have since worked a
bit more to
multi-thread all OVSDB sever features and found the changes will make OVSDB
server quite more complex.
Given that Ben is working on clustering, it may not be wise to make
two major changes
at the same time. I plan to revisit multi-threading after the
clustering changes are in.
This sounds sane. As things are going to change significantly, perhaps
I'd stop trying to put mt6 branch in the Andy's fork into testable
state. I've fixed a use-after-free bug (see the patch attached), but it
still smashes the stack or ends up with garbage in barrier->seq instead
of a pointer in ovs_barrier_block(). I haven't figured out the reason.
As for the clustering, we are currently looking for ways to scale OVSDB,
and will be happy to be early adopters for this. As I mentioned
previously, we can also contribute code if it would make things go
quicker, so I can persuade my manager this is a worthwhile investment of
time :)
Thanks,
Valentine
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
