RATIS-2129. Low replication performance because of lock contention on RaftLog #1127
Conversation
…ten blocked by RaftLog's readLock.
There was a problem hiding this comment.
Awesome design！
It seems that through this solution, we can convert the read lock of SegmentedRaftLog to the read lock of SegmentedRaftLogCache. This change means that the read-write conflicts caused by each write operation from the writing thread are now limited to when switching openSegment in SegmentedRaftLogCache. This approach appears to significantly reduce the overhead of synchronization locks.
Looking forward to future test result!
|
Hi, @szetszwo Before: We analyzed the flame graph and found that 15% of the Raftlog read locks had disappeared, which made acquiring raftlog locks faster in the write path, resulting in better write performance.This indicates that the write throughput improvement from this PR is still substantial. Before: In addition, we found that UpdateCommitIndex also takes a lot of CPU in the latest optimized scenario. It should be beneficial to continue to optimize the locking logic here. |
|
@OneSizeFitsQuorum , thanks a lot for testing this! |
szetszwo
changed the title
|
Submitted #1141 for the master branch. |
|
Hi, @szetszwo , we can close this PR because the release-3.1.x will not contain this PR and we can include this work in the future 3.2.0. |
|
Sure, let's close this. |
See RATIS-2129
(Temporally targeting to the
release-3.1.0branch. Will submit a pr for the master once this has passed all the tests.)