Skip to content
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 performance regression in Get() for block-based tables #3953

Closed
wants to merge 1 commit into from

Conversation

al13n321
Copy link
Contributor

@al13n321 al13n321 commented Jun 5, 2018

This fixes a regression in one of myrocks regression tests (readwhilewriting), introduced in 8bf555f

This PR changes two lines of code: one of them actually fixes the observed regression, the other is a mostly unrelated small fix that I'm piggy-backing here. EDIT: Nevermind, it fixes one line. More details in inline comments.

@@ -269,6 +269,9 @@ class BlockIter final : public InternalIterator {
current_ = restarts_;
status_ = s;

// Call cleanup callbacks.
Cleanable::Reset();
Copy link
Contributor Author

@al13n321 al13n321 Jun 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the fix. In my runs of the regression tests this consistently makes the regression go away.

What was probably going on is that BlockBasedTableIterator didn't unpin blocks in block cache as it transitioned from block to block. Instead it unpinned all at once when iterator is destroyed. This caused compaction iterators to take up a lot of space in block cache, leaving less for the Get()s.

Copy link
Contributor

@siying siying left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job!

@facebook-github-bot
Copy link
Contributor

@al13n321 has updated the pull request.

@al13n321
Copy link
Contributor Author

al13n321 commented Jun 5, 2018

the other is a mostly unrelated small fix that I'm piggy-backing here

Actually, nevermind that one, it's probably correct. Reverted it. Now this PR is just the performance fix.

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@al13n321 has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@sagar0
Copy link
Contributor

sagar0 commented Jun 5, 2018

I verified that this fixes the perf regression in readwhilewriting benchmark due to 8bf555f. Thanks!!

@al13n321
Copy link
Contributor Author

al13n321 commented Jun 5, 2018

Travis failed (https://travis-ci.org/facebook/rocksdb/jobs/388056399), but a few other recent PRs have the same failure (in DBTest.GroupCommitTest), so I'm assuming it's not related to this PR.

@miasantreble
Copy link
Contributor

it's a flaky test, you can ignore it

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@miasantreble is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@miasantreble
Copy link
Contributor

can't wait to land this PR, thanks @al13n321 for investigating and fixing this!

yiwu-arbug pushed a commit that referenced this pull request Jun 20, 2018
Summary:
This fixes a regression in one of myrocks regression tests (readwhilewriting), introduced in 8bf555f

This PR changes two lines of code: one of them actually fixes the observed regression, the other is a mostly unrelated small fix that I'm piggy-backing here. EDIT: Nevermind, it fixes one line. More details in inline comments.
Closes #3953

Differential Revision: D8270664

Pulled By: al13n321

fbshipit-source-id: a7d91e196807d1e816551591257c700f70e4ccac
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants