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

Implement Lock View (Sprint 3) #24199

Closed
11 of 20 tasks
MyonKeminta opened this issue Apr 22, 2021 · 9 comments
Closed
11 of 20 tasks

Implement Lock View (Sprint 3) #24199

MyonKeminta opened this issue Apr 22, 2021 · 9 comments
Assignees
Labels
sig/transaction SIG:Transaction type/enhancement The issue or PR belongs to an enhancement.

Comments

@MyonKeminta
Copy link
Contributor

MyonKeminta commented Apr 22, 2021

Development Task

We are going to implement the feature Lock View in Sprint3, which will be helpful and much improves the experience when diagnosing transaction lock contention, blocking and deadlocking issue.

The development tasks will be done by me and @longfangsong .

Design doc: #24375

Major development tasks:

Documentation

Optional improvements:

  • Record information of not-finished statement to statements_summary, so that it can be used to find statements that's being blocked and can't finish.
  • Add metrics to monitor memory usage of lock manager and deadlock detector.
  • Display internal transactions' information in TIDB_TRX
  • Avoid full scanning for TIDB_TRX and DATA_LOCK_WAITS to reduce the performance risk since TiDB automatically queries it when it encounters deadlocks.
  • Check if TIDB SQL memquota can work for lock view

Misc

@longfangsong
Copy link
Contributor

/assign "Implement DATA_LOCK_WAIT table that shows lock waiting information."

@MyonKeminta
Copy link
Contributor Author

Ok, I'm the bot :)

@MyonKeminta
Copy link
Contributor Author

@longfangsong Maybe you need to implement the get_lock_wait_info api first (Implement TiKV APIs to support exposing lock waiting information to TiDB)

@longfangsong
Copy link
Contributor

@longfangsong Maybe you need to implement the get_lock_wait_info api first (Implement TiKV APIs to support exposing lock waiting information to TiDB)

Yes, I think these two should be implemented together.

@MyonKeminta
Copy link
Contributor Author

Ok, I'll assign you both

@morgo
Copy link
Contributor

morgo commented May 24, 2021

I played around with this feature today, and it looks really useful! I have a couple of questions/suggestions:

  1. The digest seems to be the last statement executed; but the len+size relates to the whole transaction. Is it possible to actually "digest" a transaction, so that I could see the statements that it is composed of? If this is not planned initially, maybe it is better to rename it to LAST_STATEMENT_DIGEST to be clearer? I was initially confused because all my digests were the same, but that was because I was querying select * from information_schema.tidb_trx in the trx session!

  2. Related to the above question, I would love to have a way to see historical transactions as well as active (by digest). As well as locks held, I would like to know a count of the number of statements, the wall time of statements executing, and the wall time of the transaction. MySQL does not currently offer this functionality, but cockroachdb has this (and actually more).

@MyonKeminta
Copy link
Contributor Author

@morgo Thanks for your feedback!

  1. Currently the digest field shows the last executed statement, but that's actually not an expected behavior. In our design, it should show the current executing statement, which is corrected along with this PR. I agree that the naming is kind of confusing, and I'll propose a patch to the design to rename it to CURR_STMT_DIGEST. It's ok since the feature is not released in any version yet. As for the transaction digest, it sounds a good idea to me. However, it's not planned in this sprint, and I think we don't have enough time to implement it in addition.
  2. We used to discuss about the information about historical transactions, but finally we thought the time is too short in this sprint, so we didn't plan it in the first version.

Though there are many useful things we didn't plan due to the time limit, we still have chance to continue improving it in the next sprint, but it depends on our PMs' decisions. For now, I think you can still expect that it will be improved in the next version.

@MyonKeminta
Copy link
Contributor Author

Known issue +1 #25029

@MyonKeminta
Copy link
Contributor Author

Sprint 3 have ended. This issue will be closed and remaining tasks will be done in the future.
Future works will be managed by this GitHub project.

@MyonKeminta MyonKeminta changed the title Implement Lock View Implement Lock View (Sprint 3) Jul 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/transaction SIG:Transaction type/enhancement The issue or PR belongs to an enhancement.
Projects
None yet
Development

No branches or pull requests

3 participants