Measures reported by MongoGlLockWaitTest

MongoDB uses multi-granular reader-writer locking. Operations are allowed to lock at the global, database or collection level. Individual storage engines are allowed to implement their own concurrency control below the collection level (e.g., at the document-level in WiredTiger).

A global ‘instance-wide’ lock is required when some global operations - typically, short lived operations involving multiple databases - are performed. The following MongoDB operations lock multiple databases, and may hence require a global lock:

• db.copyDatabase() must lock the entire mongod instance at once.

• db.repairDatabase() obtains a global write lock and will block other operations until it finishes.

• Journaling, which is an internal operation, locks all databases for short intervals. All databases share a single journal.

• User authentication requires a read lock on the admin database for deployments using 2.6 user credentials. For deployments using the 2.4 schema for user credentials, authentication locks the admin database as well as the database the user is accessing.

• All writes to a replica set's primary lock both the database receiving the writes and then the local database for a short time. The lock for the local database allows the mongod to write to the primary's oplog and accounts for a small portion of the total time of the operation.

MongoDB uses a readers-writer [ed: also known as “multi-reader” or “shared exclusive”] lock that allows concurrent reads access, but gives exclusive access to a single write operation. When a read lock exists, many read operations may use this lock. However, when a write lock exists, a single write operation holds the lock exclusively, and no other read or write operations may share the lock. If read or write requests are received by a database instance on which a write lock pre-exists, such requests will be placed in a queue, where they will wait until the write lock is released. While some level of queuing is to be expected, an abnormal number of enqueued requests is a cause for concern, as it only means that application requests are being continuously blocked; if the problem persists, it can cause application performance to suffer greatly. It is therefore imperative that requests waiting in queues for locks are tracked and consistent increase in this request count brought to the attention of administrators. This is what the MongoGlLockWaitTest test does.

This test monitors the current global lock queue of a Mongo database server and reports the total count of requests in the queue. Additionally, the test also reports how many of these enqueued requests are read requests and how many are write requests. This way, the test indicates whether/not locks are released and granted to new requests in a timely manner. Locking inefficiencies are thus revealed. In addition, the test also indicates what type of requests the server is blocking more - read requests? or write requests? From this, administrators can figure out what type of lock currently exists on the server being monitored - read lock? or write lock?

Outputs of the test : One set of results for the target Mongo database server being monitored.

The measures made by this test are as follows: