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

store/tikv: fix performance issue under mixed transaction mode #10847

Merged
merged 7 commits into from
Jun 20, 2019

Conversation

coocood
Copy link
Member

@coocood coocood commented Jun 19, 2019

What problem does this PR solve?

  • When optimistic transaction and pessimistic transactions conflicts, the performance was terribly low.
    The reason is that if an optimistic wait for a pessimistic lock during prewrite, the other successfully written prewrite locks blocks all the reads.
  • When tikv returns a lock with zero TTL, we don't respect it but set it to a default 3000 value which causes an undesired wait, can lead to transaction failure.

What is changed and how it works?

  • Return ErrWriteConflict when optimistic prewrite meets a pessimistic lock.
  • Don't modify the TTL value.

Check List

Tests

  • Unit test

Related changes

  • Need to cherry-pick to the release branch

@coocood
Copy link
Member Author

coocood commented Jun 19, 2019

@youjiali1995 @tiancaiamao PTAL

@coocood
Copy link
Member Author

coocood commented Jun 19, 2019

/run-all-tests

@@ -538,6 +538,19 @@ func (c *twoPhaseCommitter) prewriteSingleBatch(bo *Backoffer, batch batchKeys)
if err1 != nil {
return errors.Trace(err1)
}
if !c.isPessimistic && lock.TTL >= uint64(config.MinPessimisticTTL/time.Millisecond) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Large transaction's TTL may be greater than MinPessimisticTTL. The comment below isn't accurate.

@codecov
Copy link

codecov bot commented Jun 19, 2019

Codecov Report

Merging #10847 into master will decrease coverage by 0.0252%.
The diff coverage is 100%.

@@               Coverage Diff                @@
##             master     #10847        +/-   ##
================================================
- Coverage   80.9119%   80.8867%   -0.0253%     
================================================
  Files           419        419                
  Lines         88663      88666         +3     
================================================
- Hits          71739      71719        -20     
- Misses        11703      11727        +24     
+ Partials       5221       5220         -1

@coocood
Copy link
Member Author

coocood commented Jun 19, 2019

/run-all-tests

@coocood
Copy link
Member Author

coocood commented Jun 19, 2019

/run-all-tests

@tiancaiamao
Copy link
Contributor

LGTM

@tiancaiamao tiancaiamao added the status/LGT1 Indicates that a PR has LGTM 1. label Jun 19, 2019
@youjiali1995
Copy link
Contributor

LGTM

@youjiali1995 youjiali1995 added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Jun 19, 2019
@coocood
Copy link
Member Author

coocood commented Jun 20, 2019

/run-all-tests

@coocood
Copy link
Member Author

coocood commented Jun 20, 2019

/run-unit-test

1 similar comment
@coocood
Copy link
Member Author

coocood commented Jun 20, 2019

/run-unit-test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/tikv status/LGT2 Indicates that a PR has LGTM 2.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants