-
Notifications
You must be signed in to change notification settings - Fork 774
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
do not cache large blob history event #4621
Conversation
take a look at https://github.com/temporalio/temporal/blob/master/common/cache/lru.go
|
99f9e64
to
f4998b8
Compare
f4998b8
to
406fd0d
Compare
8044317
to
d9fc32c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
common/cache/lru.go
Outdated
@@ -290,6 +302,7 @@ func (c *lru) putInternal(key interface{}, value interface{}, allowUpdate bool) | |||
entry := &entryImpl{ | |||
key: key, | |||
value: value, | |||
size: getSize(value), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shall we still do the check of size v.s. cache max size and return error early if item size is too big.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, I move the size validation on the top before entry created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I mean we don't have to evict any entry if new item size is too big.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks for clarify. I don't feel strong here, I will make the change to do the check before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, run the loop twice will make the logic looks duplicate and complex. do you feel strong about check before eviction?
ee63d9a
to
9c2b0ee
Compare
2da58f2
to
b6171a6
Compare
<!-- Describe what has changed in this PR --> **What changed?** change history cache key from history.eventsCache*Size to history.eventsCache*SizeBytes <!-- Tell your future self why have you made these changes --> It will remove the key name confusion since cache size definition changed in: #4621 <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> unittests <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?**
<!-- Describe what has changed in this PR --> **What changed?** change history cache key from history.eventsCache*Size to history.eventsCache*SizeBytes <!-- Tell your future self why have you made these changes --> It will remove the key name confusion since cache size definition changed in: #4621 <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> unittests <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?**
<!-- Describe what has changed in this PR --> **What changed?** change history cache key from history.eventsCache*Size to history.eventsCache*SizeBytes <!-- Tell your future self why have you made these changes --> It will remove the key name confusion since cache size definition changed in: #4621 <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> unittests <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?**
<!-- Describe what has changed in this PR --> **What changed?** change history cache key from history.eventsCache*Size to history.eventsCache*SizeBytes <!-- Tell your future self why have you made these changes --> It will remove the key name confusion since cache size definition changed in: #4621 <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> unittests <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?**
<!-- Describe what has changed in this PR --> **What changed?** change history cache key from history.eventsCache*Size to history.eventsCache*SizeBytes <!-- Tell your future self why have you made these changes --> It will remove the key name confusion since cache size definition changed in: #4621 <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> unittests <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?**
This reverts commit f97b681.
<!-- Describe what has changed in this PR --> **What changed?** remove the cache initial size from lru cache and related configs. also refactor putInternal to better support different scenarios. and added more unittests for cache size. <!-- Tell your future self why have you made these changes --> **Why?** in #4621 I change the history cache to use item bytes instead item count. However it accidentally touched default number of key when cache initialized <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> **How did you test it?** unittest <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** Memory usage increase and pined mutable state will never leave the cache, which cause block workflow. <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?**
What changed?
Allow lru cache size check against with CacheSize() method.
Why?
We want to limit the history event cache by BytesSize.
How did you test it?
unittest
Potential risks
Is hotfix candidate?