Uh oh!
There was an error while loading. Please reload this page.
HBASE-27558 Scan quotas and limits should account for total block IO - #4967
Merged
Conversation
Apache-HBase
commented
Jan 14, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 14, 2023
💔 -1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 14, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 14, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 14, 2023
💔 -1 overall
This message was automatically generated. |
bbeaudreaultforce-pushed
the
HBASE-27558
branch
from
January 16, 2023 15:25
dd7170b to
7f7c8b6Comparebbeaudreault
marked this pull request as ready for review
January 16, 2023 15:25
bbeaudreault
commented
Jan 16, 2023
ContributorAuthor
Pushed tests, marking ready for review. |
Apache-HBase
commented
Jan 16, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 16, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 16, 2023
🎊 +1 overall
This message was automatically generated. |
Apache9
reviewed
Jan 18, 2023
| * Returns the block size in bytes for the current block. Will only return a value once per block, | ||
| * otherwise 0. Used for calculating block IO in ScannerContext. | ||
| */ | ||
| int getCurrentBlockSizeOnce(); |
Contributor
There was a problem hiding this comment.
This API design is a bit strange... Let me take a look on the usage...
Contributor
There was a problem hiding this comment.
I think it is better to introduce a method called recordBlockSize? The comment could say that the implementation should make sure that for every block we only record once.
ContributorAuthor
There was a problem hiding this comment.
That seems intuitive and reasonable. Done. Please see latest commit.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| return scannerContext.setScannerState(NextState.NO_MORE_VALUES).hasMoreValues(); | ||
| } | ||
| if (!shouldStop) { | ||
| // Read nothing as the cells were filtered, but still need to check time limit. |
Contributor
There was a problem hiding this comment.
Why we need to add a check here?
ContributorAuthor
There was a problem hiding this comment.
We want to check the size limit any time we are potentially continuing the loop. This was the only case we missed, the others (which i converted from checkTimeLimit to checkAnyLimit above) are all similar.
Since nextRow is now accumulating block size, we want to check after calling nextRow to ensure we haven't exceeded the limit.
I could make this checkSizeLimit if you'd like. I made it checkAnyLimitReached so that it is the same as the other calls above, which were just checking time limit.
ContributorAuthor
There was a problem hiding this comment.
To be honest, I think this should have been here all along and was just missed along the way. I'm not sure why we'd want to check time limit for the nextRow calls above but not this one. This check here ensures that populating from joined heap + nextRow does not exceed time or (new) size limit.
Contributor
There was a problem hiding this comment.
This method is on the critial path of reading, and the code here will executed every time when we get a row, so it may affect scan performance if we add more checks here.
I just mean is it a must to have a check here? Why we do not need to check here in the past...
ContributorAuthor
There was a problem hiding this comment.
Actually, this section of the method is not nearly as hot as the rest of the method. The only real way we reach this point is when filter.filterRowCells(kvs) clears all cells from the results after having been accumulated in StoreScanner. There are only 2 standard filters which do this -- DependentColumnFilter and SingleColumnValueExcludeFilter.
That said, you do make a good point. We have never had a time limit here, so we may not need it. We do need a size limit check here, now that we track block sizes. Previously, we would not check size limit here because the results are empty so wouldn't have accumulated size progress. Now that we accumulate block size progress even for filtered rows, we need a check.
For this type of scan, we will have accumulated blocks in both populateResults() and possibly nextRow(). Right after populateResults() there's a scannerContext.checkAnyLimitReached(LimitScope.BETWEEN_CELLS) call. That call doesn't protect against this case, because it passes BETWEEN_CELLS. For scans with filter.hasFilterRow(), the limit scope is changed to LimitScope.BETWEEN_ROWS. So this check is skipped for these. Scans which enter this code block will have skipped all other limit checks above. The checkSizeLimit I add here is the only safe place we can check BETWEEN_ROWS for these types of filtered scans.
The best way to illustrate this is with a test -- I just pushed a change which does the following:
- Change this line to just
checkSizeLimit - Adds a new test
testCheckLimitAfterFilteringRowCells
If I comment out this checkSizeLimit, the added test fails -- the whole scan is able to complete in 1 rpc instead of the expected 4. So this illustrates that we need to have a size check here.
Personally I think it's also accurate to have a time limit check here, because for these types of scans I think they'd be able to circumvent our existing time limits. But within the scope of this JIRA, I can keep it to just size limit for now.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Apache9
reviewed
Jan 20, 2023
| * Returns the block size in bytes for the current block. Will only return a value once per block, | ||
| * otherwise 0. Used for calculating block IO in ScannerContext. | ||
| */ | ||
| int getCurrentBlockSizeOnce(); |
Contributor
There was a problem hiding this comment.
I think it is better to introduce a method called recordBlockSize? The comment could say that the implementation should make sure that for every block we only record once.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| return scannerContext.setScannerState(NextState.NO_MORE_VALUES).hasMoreValues(); | ||
| } | ||
| if (!shouldStop) { | ||
| // Read nothing as the cells were filtered, but still need to check time limit. |
Contributor
There was a problem hiding this comment.
This method is on the critial path of reading, and the code here will executed every time when we get a row, so it may affect scan performance if we add more checks here.
I just mean is it a must to have a check here? Why we do not need to check here in the past...
bbeaudreault
commented
Jan 20, 2023
ContributorAuthor
Thanks for sticking with me on this @Apache9. Great feedback. I've pushed changes based on your recent comments and provided some extra context on a couple of your comments. For some reason they don't show up as responses to your most recent review, but you should see them if you scroll up. |
Apache-HBase
commented
Jan 20, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 20, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 20, 2023
🎊 +1 overall
This message was automatically generated. |
Apache9
reviewed
Jan 28, 2023
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
bbeaudreaultforce-pushed
the
HBASE-27558
branch
from
January 29, 2023 02:51
9ebcfce to
cfd4b55CompareApache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 29, 2023
💔 -1 overall
This message was automatically generated. |
Apache9
reviewed
Jan 29, 2023
Apache9
left a comment
Contributor
There was a problem hiding this comment.
Thanks for the comment. Much clear now. I think we are almost there~
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
Apache9
approved these changes
Jan 30, 2023
bbeaudreault added a commit
that referenced
this pull request
Jan 30, 2023
…4967) Signed-off-by: Duo Zhang <zhangduo@apache.org>
bbeaudreault added a commit
to HubSpot/hbase
that referenced
this pull request
Feb 5, 2023
…pache#4967) Signed-off-by: Duo Zhang <zhangduo@apache.org>
bbeaudreault added a commit
to HubSpot/hbase
that referenced
this pull request
Feb 10, 2023
…pache#4967) Signed-off-by: Duo Zhang <zhangduo@apache.org>
bbeaudreault added a commit
to HubSpot/hbase
that referenced
this pull request
Feb 10, 2023
…pache#4967) Signed-off-by: Duo Zhang <zhangduo@apache.org>
bbeaudreault added a commit
to HubSpot/hbase
that referenced
this pull request
Feb 28, 2023
…or total block IO (apache#4967) Signed-off-by: Duo Zhang <zhangduo@apache.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've deployed this on a test cluster and verified that it helps to reduce excess retained blocks due to heavily filtered scans. It is nice to have a upper limit on the cost of a scan, whether filtered or unfiltered and equally applying to both.