Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optimize get term #438

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

optimize get term #438

wants to merge 1 commit into from

Conversation

CkTD
Copy link

@CkTD CkTD commented Feb 27, 2024

leader 上 _logs_in_memory 中缓存的 LogEntry 会在 apply 完成且写到盘上后被清理掉。
leader 在 append_entries rpc 中需要获取 prev_log_term。

如果请求的并发比较小,发送新Log时,前一个LogEntry 很有可能已经从缓存清理掉了,prev_log_term 只能从 LogStorage 获取。(场景: 一个server上,node 数量特别多,但是单个node qps 比较小,能观察到 bvar raft_read_term_from_storage_second 很高)

这个 pr 在 clear_memory_logs 时多保留 log,使得上面场景总能通过缓存查询到 prev_log_term。
如果长时间不写,最后这个保留的 log 会在打快照的时候被清理掉。

@ehds
Copy link
Contributor

ehds commented Apr 9, 2024

即使是从 LogStorage get_term, 在初始化时 每个 segment 都会缓存其 meta 信息(index->(term,offset)) ,所以也只是需要查找内存。
比起读 memoryLog ,会多一次查找 segment 和读取 meta 的开销(也会多一些判断和内存跳转以及锁的开销)。如果是 qps 比较低的情况,有评估过对性能的影响有多大吗?

@CkTD
Copy link
Author

CkTD commented Jun 4, 2024

即使是从 LogStorage get_term, 在初始化时 每个 segment 都会缓存其 meta 信息(index->(term,offset)) ,所以也只是需要查找内存。 比起读 memoryLog ,会多一次查找 segment 和读取 meta 的开销(也会多一些判断和内存跳转以及锁的开销)。如果是 qps 比较低的情况,有评估过对性能的影响有多大吗?

我这里的测试场景下 AppendEntries RPC 的时延 < 1ms。 一个 node get_term 的频率能达到每秒上千次。

测试性能的时候是用了一个自己开发的LogStorage,用 contention profiler 能看到由于读term造成的锁竞争比较明显。默认的 LogStorage还没观察过

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants