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
raftstore: accumulated read index requests may result in a large number of re-propose actions, increasing pressure on the store loop #16960
Comments
why do we want to send it for each request and we batch them instead. |
@mittalrishabh |
|
|
Can't we maintain another copy of memory locks in follower so that read index doesn't need to check for memory locks. |
It will introduce greate impact on concurrency control complexity and write performance. |
Thanks. I will go through the above link. Does it make sense to send batch read index to reduce the number of RPC calls. |
It could be an improvement I think, like re-propose the pending requests whose responses are regarded as lost within one message or RPC call. |
Development Task
After #8926 and #9721, an
addition_request
is introduced to indicate whether the memory lock check is done for the follower or replica read requests.When a
ReadIndexResp
is recived andapply_reads
is called, the read index request would be re-proposed if lock check is not finished.Consider a situation, when the number of follower read requests spike on a tikv node, and the read index response is not processed and returned in time from the leader peer, for example the leader peer is busy or there is something with the raft connections, these requests would be pending in the
ReadIndexQueue
.When the
ReadIndexResp
is received after some time,MsgReadIndex
message would be re-sent for each pending request to the leader peer, resulting spike of this type of raft messages, increasing the pressure on the raft store loop.The logs are like
A lot of
re-propose
requests are sent with a few miliseconds.It's better to find a strategy to avoid such spikes to avoid tail latency caused by pressure on the raft store loop.
The text was updated successfully, but these errors were encountered: