[ovs-dev] [PATCH] ovsdb: provide raft and command interfaces with priority
anton.ivanov at cambridgegreys.com
Fri Jun 11 06:05:08 UTC 2021
On 10/06/2021 23:01, Ben Pfaff wrote:
> On Tue, Jun 08, 2021 at 10:27:08AM +0100, anton.ivanov at cambridgegreys.com wrote:
>> From: Anton Ivanov <anton.ivanov at cambridgegreys.com>
>> Set a soft time limit of "raft election timer"/2 on ovsdb
>> 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 <anton.ivanov at cambridgegreys.com>
> Personally I'd consider a random or round-robin processing order to be
> pretty critical here.
I will send a revised patch with either round-robin or "restart where it
> 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
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
More information about the dev