[SERVER-39858] Provide a command to list all locks Created: 27/Feb/19 Updated: 01/Mar/19 Resolved: 01/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Dmitry Ryabtsev | Assignee: | Geert Bosch |
| Resolution: | Done | Votes: | 15 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Storage NYC 2019-03-11 | ||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| Description |
|
Support engineers have to inspect mongod logs whenever there is a locking related issue. That approach is suboptimal as logs can be large and not straightforward to process. Also log analysis is often time consuming. Another approach is to get the locks information from the db.currentOp() output, however the output of that command is thread-centric, not lock centric. Often the question is simply "who's holding the global/database/collection lock". It should not be required to iterate through all of the threads in the db.currentOp() output to get the answer. It would be great to have a separate command that would produce a list of the MongoDB locks (e.g. Global, Metadata, Database, Collection; the latter two should indicate the names of the database objects associated with them) along with the information on the threads (e.g. thread names) that are holding them. The command should not be blocking and should not require a lock (not sure if doable). |
| Comments |
| Comment by Geert Bosch [ 28/Feb/19 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Indeed, the lockInfo command gives you all information you need to know which op is blocked by which op. Because it lists theĀ opid, it's easy to see what offending operation to kill. | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Dmitry Ryabtsev [ 28/Feb/19 ] | ||||||||||||||||||||||||||||||||||||||||||
|
From a quick test:
| ||||||||||||||||||||||||||||||||||||||||||
| Comment by Kevin Pulo [ 28/Feb/19 ] | ||||||||||||||||||||||||||||||||||||||||||
|
There's a (little-known and possibly internal) lockInfo admin command, which returns a dump of the LockManager's current state. Is this the desired info, or close to it? | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Bruce Lucas (Inactive) [ 27/Feb/19 ] | ||||||||||||||||||||||||||||||||||||||||||
|
If we implement the infrastructure for reporting this information, I suspect it would be a simple matter to use it to also report (either in mongod log or in error returned to application) who is holding a strong lock when an transaction fails because it can't acquire an intent lock, which should help customers debug such problems. |