[SERVER-8622] serverStatus blocks waiting for various locks Created: 19/Feb/13  Updated: 06/Dec/22  Resolved: 23/Feb/17

Status: Closed
Project: Core Server
Component/s: Admin
Affects Version/s: 2.4.0-rc0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-16146 dropDatabase is slow and returns succ... Closed
Related
is related to DOCS-1142 Document serverStatus lock usage Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

Here is a quick analysis of the locks hanging off serverStatus:

  • recordStats requires a read lock (Client::ReadContext) for each db
  • locks requires "DBLocksMap::ref r(dblocks);" (not write lock related)
  • cursors requires client cursor lock
  • network requires local lock for network counters
  • repl requires lock on "ReplSetImpl"
    • master/slave: local db, and possibly queries all replication sources (other server oplog entries – first/last entry).

The biggest issue is the recordStats since that requires a read lock for each db.



 Comments   
Comment by Eric Milkie [ 23/Feb/17 ]

There will always be locking necessary to glean the information needed by the various serverStatus sections.

Comment by Scott Hernandez (Inactive) [ 14/Nov/14 ]

In recent versions new sections also require new locking like storageEngine (wiredtiger) and rangeDelete, for example.

Comment by Scott Hernandez (Inactive) [ 20/Feb/13 ]

To work around this issue you can conditionally disable sections from being run/displayed like this:

db.serverStatus({recordStats:0, locks:0}) // don't run or return the recordStats nor locks sections.

Generated at Thu Feb 08 03:17:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.