-
Notifications
You must be signed in to change notification settings - Fork 57
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
fix(store): limit dbPageSize #1018
Conversation
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.
Sorry if my comments sound a little nitpicked 🙏🏼
@@ -267,8 +267,12 @@ method getAll*(db: WakuMessageStore, onData: message_store.DataProc): MessageSto | |||
ok gotMessages | |||
|
|||
proc adjustDbPageSize(dbPageSize: uint64, matchCount: uint64, returnPageSize: uint64): uint64 {.inline.} = | |||
var ret = if matchCount < 2: dbPageSize * returnPageSize | |||
const maxDbPageSize: uint64 = 20000 # the maximum DB page size is limited to prevent excessive use of memory in case of very sparse or non-matching filters. TODO: dynamic, adjust to available memory |
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.
Could you put this constant outside of the function?
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 put it there because it is part of the heuristic of finding the "optimal" page size. In the future, this could change.
Did not want to clutter the outer scope with it. wdyt? No strong opinion here.
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.
Ok, then LGTM ✅😁
Co-authored-by: Lorenzo Delgado <[email protected]>
Co-authored-by: Lorenzo Delgado <[email protected]>
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. No strong opinion about where the const
resides, but since it is a workaround "stand-in" for a heuristic I'm fine with it hiding in scope.
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 ✅
Just as info: Most likely, the dbPageSize will be replaced by putting the filtering into the WHERE clause in the future. |
There is a known issue in `v0.10` where certain store queries can slow down nodes: waku-org/nwaku#1017 A possible (partial?) fix has been merged and deployed to `wakuv2.test`: waku-org/nwaku#1018 But the SQLite store can be disable on `prod` in the meantime. Signed-off-by: Jakub Sokołowski <[email protected]>
Otherwise nodes try to load all messages into memory at startup. And the issue that originally caused this to be disabled is closed: waku-org/nwaku#1017 waku-org/nwaku#1018 Signed-off-by: Jakub Sokołowski <[email protected]>
This PR limits
dbPageSize
avoiding excessive use of memory in case of sparse or non-matching filters.This PR partly solves #1017