[SERVER-34787] currentOp should report locks held and locks waiting to be acquired separately; and report lock ResourceIds Created: 02/May/18  Updated: 06/Dec/22  Resolved: 02/Mar/20

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: SWDI, nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Storage Execution
Sprint: Execution Team 2019-07-01, Execution Team 2019-07-15
Participants:

 Description   

currentOp should report locks held and locks waiting to be acquired separately. For example, in this excerpt from a currentOp op result,  the lock we're waiting for is presumably the Database W (X), but it should say so.

"locks" : {
      "Global" : "w",
      "Database" : "W"
},
"waitingForLock" : true,
"lockStats" : {
      "Global" : {
            "acquireCount" : {
                  "r" : NumberLong(1),
                  "w" : NumberLong(1)
            },
      },
      "Database" : {
            "acquireCount" : {
                  "W" : NumberLong(1)                
            },
            "acquireWaitCount" : {
                  "W" : NumberLong(1)
            },
            "timeAcquiringMicros" : {
                  "W" : NumberLong(784623211)      
            }
}

Additionally, we have access to ResourceId information when reporting the lock information. We should add that information so that we don't have to infer which ops must be trying to get which collection/database locks from the fact that they are deadlocking. There are internal ops that either don't have the "ns" field filled out, or take collection and oplog locks; and there are transactions that now take locks across collections/databases. In conclusion, the ResourceIds would be nice to have.

 

 



 Comments   
Comment by Connie Chen [ 02/Mar/20 ]

We would rather not change LockerInfo currently to prevent confusion and because we are moving toward a lock-free world where it will not be less valuable

Comment by Dianna Hohensee (Inactive) [ 18/Jun/19 ]

I started looking into what lock information we currently have to surface. Preliminary findings

  • fillLockerInfo looks like it's what currentOp uses to construct the locks and lockStats fields.
  • It doesn't look like LockerInfo currently maintains info about what locks are pending (at least on first look).
  • LockState keeps a _stats object for itself.
  • It looks like lockBegin will track that a lock acquisition request occurred, but lockComplete doesn't appear to set anything about finally acquiring that lock, so I don't think we have that info currently.
Comment by Bruce Lucas (Inactive) [ 17/Jun/19 ]

Can you summarize here the specific proposed changes to currentOp once you have a better idea?

Generated at Thu Feb 08 04:37:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.