On 10/06/2021 23:01, Ben Pfaff wrote:
On Tue, Jun 08, 2021 at 10:27:08AM +0100, [email protected] wrote:
From: Anton Ivanov <[email protected]>
Set a soft time limit of "raft election timer"/2 on ovsdb
processing.
This improves behaviour in large heavily loaded clusters.
While it cannot fully eliminate spurious raft elections
under heavy load, it significantly decreases their number.
TODO: randomize session processing order to ensure individual
sessions towards the end of the remotes list are not starved
Signed-off-by: Anton Ivanov <[email protected]>
Personally I'd consider a random or round-robin processing order to be
pretty critical here.
I agree.
I will send a revised patch with either round-robin or "restart where it
stopped".
A better approach (which would be a lot more work) would be for the Raft
code to use a separate thread or process.
Looked at that from several angles. Not realistic without a complete
rewrite:
1. The amount of locking needed will be severely detrimental to
performance. I tried at some point to play with putting all monitors
processing into a parallel pool and it needed on the order of 4-5
mutexes per monitor protecting different parts of it. Storage is likely
to be even worse.
2. It will end up pushing storage state that does not correspond to a
complete transaction which is a can of worms in its own right.
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
