Add a cache eviction policy:Evicting cache data by the slowest markDeletedPosition - #14985
Conversation
|
@eolivelli @Technoboy- @codelipenghui |
eolivelli
left a comment
There was a problem hiding this comment.
Make sense, especially if you have some numbers to share.
Can you please add a test case ?
cc @merlimat @rdhabalia WDTY?
OK ,I will fix! |
Jason918
left a comment
There was a problem hiding this comment.
Make sense. IMO, markDeletedPosition is better than readPosition in normal case. Maybe we can use markDeletedPosition by default, and use readPosition iff overall cache usage is over some threshold (like 85%)?
OK, I aggree. |
|
Make sense to me. |
In the scenario of message re-pushing, this way of dynamically adjusting the eviction policy is not suitable. I can reopen a discussion about dynamically adjusting the eviction policy later. |
Fixed. PTAL,thanks! @Jason918 @eolivelli @aloyszhang |
|
/pulsarbot run-failure-checks |
2 similar comments
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
7 similar comments
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
5 similar comments
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
@eolivelli PTAL,thanks! |
|
ping |
…letedPosition (apache#14985) (cherry picked from commit 9b36dcd)
…t markDeletedPosition (apache#14985)" This reverts commit ee28018.
…letedPosition (apache#14985) (cherry picked from commit 9b36dcd)
Motivation
We found a problem: even if we adjusted the cache eviction size and time a lot, there would still be some misscaches when the client restarted.The corresponding configuration is as follows:
managedLedgerCacheSizeMB=40960
managedLedgerCacheEvictionTimeThresholdMillis=1800000
The current cache eviction strategy is to evict according to the read position, so there may be a miss cache when the data is pushed again.
In our scenario, there are tens of thousands of clients, and they are deployed on k8s. In order to save resources, they may dynamically expand or shrink, so that data re-pushing will happen from time to time:


Modifications
Therefore, to improve the cache hit rate , I think a new cache eviction strategy should be added: evict data according to the markdelete position.
Documentation
Check the box below or label this PR directly (if you have committer privilege).
Need to update docs?
doc-required(If you need help on updating docs, create a doc issue)
no-need-doc(Please explain why)
doc(If this PR contains doc changes)