Skip to content

lock_manager: Skip updating lock wait info for non-fair-locking requests#17500

Merged
ti-chi-bot[bot] merged 2 commits intotikv:release-8.1from
MyonKeminta:m/remove-update-lock-wait-for-non-fair-locking-requests
Sep 10, 2024
Merged

lock_manager: Skip updating lock wait info for non-fair-locking requests#17500
ti-chi-bot[bot] merged 2 commits intotikv:release-8.1from
MyonKeminta:m/remove-update-lock-wait-for-non-fair-locking-requests

Conversation

@MyonKeminta
Copy link
Contributor

@MyonKeminta MyonKeminta commented Sep 9, 2024

What is changed and how it works?

Issue Number: Close #17394

What's Changed:

lock_manager: Skip updating lock wait info for non-fair-locking requests

This is a simpler and lower-risky fix of the OOM issue #17394 for released branches, as an alternative solution to #17451 .
In this way, for acquire_pessimistic_lock requests without enabling fair locking, the behavior of update_wait_for will be a noop. So that if fair locking is globally disabled, the behavior will be equivalent to versions before 7.0.

This is a simple alternative solution to #17451 .
For non-fair locking scenario, it's confirmed that the problem can be avoided.

Before:
image

After:
image

Related changes

  • PR to update pingcap/docs/pingcap/docs-cn:
  • Need to cherry-pick to the release branch

Check List

Tests

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below)
  • No code

Side effects

  • Performance regression: Consumes more CPU
  • Performance regression: Consumes more Memory
  • Breaking backward compatibility

Release note

Fix an issue that when frequently updating a row while many transaction is waiting on the lock, it might sometimes cause TiKV OOM

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>
@ti-chi-bot
Copy link
Contributor

ti-chi-bot bot commented Sep 9, 2024

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@ti-chi-bot ti-chi-bot bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note Denotes a PR that will be considered when it comes time to generate release notes. do-not-merge/cherry-pick-not-approved dco-signoff: yes Indicates the PR's author has signed the dco. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Sep 9, 2024
@MyonKeminta
Copy link
Contributor Author

/release

@sre-bot
Copy link
Contributor

sre-bot commented Sep 9, 2024

@MyonKeminta MyonKeminta marked this pull request as ready for review September 10, 2024 06:25
@ti-chi-bot ti-chi-bot bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 10, 2024
@MyonKeminta MyonKeminta added needs-cherry-pick-release-7.1 Should cherry pick this PR to release-7.1 branch. needs-cherry-pick-release-7.5 Should cherry pick this PR to release-7.5 branch. labels Sep 10, 2024
@ti-chi-bot ti-chi-bot bot added the needs-1-more-lgtm Indicates a PR needs 1 more LGTM. label Sep 10, 2024
@ti-chi-bot
Copy link
Contributor

ti-chi-bot bot commented Sep 10, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ekexium, zyguan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ti-chi-bot ti-chi-bot bot added lgtm approved and removed needs-1-more-lgtm Indicates a PR needs 1 more LGTM. labels Sep 10, 2024
@ti-chi-bot
Copy link
Contributor

ti-chi-bot bot commented Sep 10, 2024

[LGTM Timeline notifier]

Timeline:

  • 2024-09-10 07:15:03.527791503 +0000 UTC m=+340573.268215436: ☑️ agreed by zyguan.
  • 2024-09-10 07:45:42.403820051 +0000 UTC m=+342412.144244012: ☑️ agreed by ekexium.

@ti-chi-bot ti-chi-bot bot added cherry-pick-approved Cherry pick PR approved by release team. and removed do-not-merge/cherry-pick-not-approved labels Sep 10, 2024
@cfzjywxk
Copy link
Collaborator

/merge

@ti-chi-bot
Copy link
Contributor

ti-chi-bot bot commented Sep 10, 2024

@cfzjywxk: We have migrated to builtin LGTM and approve plugins for reviewing.

👉 Please use /approve when you want approve this pull request.

The changes announcement: Proposal: Strengthen configuration change approval.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.

@ti-chi-bot ti-chi-bot bot merged commit 2d6991c into tikv:release-8.1 Sep 10, 2024
@MyonKeminta MyonKeminta deleted the m/remove-update-lock-wait-for-non-fair-locking-requests branch September 10, 2024 09:05
@ti-chi-bot
Copy link
Member

In response to a cherrypick label: new pull request created to branch release-7.1: #17516.

@ti-chi-bot
Copy link
Member

In response to a cherrypick label: new pull request created to branch release-7.5: #17517.

ti-chi-bot bot pushed a commit that referenced this pull request Sep 10, 2024
…sts (#17500) (#17516)

close #17394

lock_manager: Skip updating lock wait info for non-fair-locking requests

This is a simpler and lower-risky fix of the OOM issue #17394 for released branches, as an alternative solution to #17451 .
In this way, for acquire_pessimistic_lock requests without enabling fair locking, the behavior of update_wait_for will be a noop. So that if fair locking is globally disabled, the behavior will be equivalent to versions before 7.0.

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>

Co-authored-by: MyonKeminta <MyonKeminta@users.noreply.github.com>
ti-chi-bot bot pushed a commit that referenced this pull request Sep 10, 2024
…sts (#17500) (#17517)

close #17394

lock_manager: Skip updating lock wait info for non-fair-locking requests

This is a simpler and lower-risky fix of the OOM issue #17394 for released branches, as an alternative solution to #17451 .
In this way, for acquire_pessimistic_lock requests without enabling fair locking, the behavior of update_wait_for will be a noop. So that if fair locking is globally disabled, the behavior will be equivalent to versions before 7.0.

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>

Co-authored-by: MyonKeminta <MyonKeminta@users.noreply.github.com>
@MyonKeminta MyonKeminta added the needs-cherry-pick-release-8.5 Should cherry pick this PR to release-8.5 branch. label Nov 20, 2024
@ti-chi-bot
Copy link
Member

In response to a cherrypick label: new pull request created to branch release-8.5: #17869.

MyonKeminta added a commit to MyonKeminta/tikv that referenced this pull request Nov 20, 2024
…sts (tikv#17500)

close tikv#17394

lock_manager: Skip updating lock wait info for non-fair-locking requests

This is a simpler and lower-risky fix of the OOM issue tikv#17394 for released branches, as an alternative solution to tikv#17451 .
In this way, for acquire_pessimistic_lock requests without enabling fair locking, the behavior of update_wait_for will be a noop. So that if fair locking is globally disabled, the behavior will be equivalent to versions before 7.0.

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>
ti-chi-bot bot pushed a commit that referenced this pull request Nov 20, 2024
…sts (#17500) (#17870)

close #17394

lock_manager: Skip updating lock wait info for non-fair-locking requests

This is a simpler and lower-risky fix of the OOM issue #17394 for released branches, as an alternative solution to #17451 .
In this way, for acquire_pessimistic_lock requests without enabling fair locking, the behavior of update_wait_for will be a noop. So that if fair locking is globally disabled, the behavior will be equivalent to versions before 7.0.

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>
ti-chi-bot bot pushed a commit that referenced this pull request Nov 20, 2024
…sts (#17500) (#17869)

close #17394

lock_manager: Skip updating lock wait info for non-fair-locking requests

This is a simpler and lower-risky fix of the OOM issue #17394 for released branches, as an alternative solution to #17451 .
In this way, for acquire_pessimistic_lock requests without enabling fair locking, the behavior of update_wait_for will be a noop. So that if fair locking is globally disabled, the behavior will be equivalent to versions before 7.0.

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>

Co-authored-by: MyonKeminta <MyonKeminta@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved cherry-pick-approved Cherry pick PR approved by release team. dco-signoff: yes Indicates the PR's author has signed the dco. lgtm needs-cherry-pick-release-7.1 Should cherry pick this PR to release-7.1 branch. needs-cherry-pick-release-7.5 Should cherry pick this PR to release-7.5 branch. needs-cherry-pick-release-8.5 Should cherry pick this PR to release-8.5 branch. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants