serverStatus¶

Definition¶

serverStatus¶

The serverStatus command returns a document that provides an overview of the database process’s state. Most monitoring applications run this command at a regular interval to collection statistics about the instance:

{ serverStatus: 1 }

The value (i.e. 1 above), does not affect the operation of the command.

Changed in version 2.4: In 2.4 you can dynamically suppress portions of the serverStatus output, or include suppressed sections by adding fields to the command document as in the following examples:

db.runCommand( { serverStatus: 1, repl: 0 } )
db.runCommand( { serverStatus: 1, metrics: 0, locks: 0 } )

serverStatus includes all fields by default, except rangeDeleter and some content in the repl document.

Note

You may only dynamically include top-level fields from the serverStatus document that are not included by default. You can exclude any field that serverStatus includes by default.

Output¶

The serverStatus command returns a collection of information that reflects the database’s status. These data are useful for diagnosing and assessing the performance of your MongoDB instance. This reference catalogs each datum included in the output of this command and provides context for using this data to more effectively administer your database.

Changed in version 3.0: The server status output no longer includes the workingSet, indexCounters, and recordStats sections.

For an example of the serverStatus output, see Server Status Output.

Instance Information¶

For an example of the instance information, see the Instance Information section of the Server Status Output page.

serverStatus.host¶: The host field contains the system’s hostname. In Unix/Linux systems, this should be the same as the output of the hostname command.

serverStatus.version¶: The version field contains the version of MongoDB running on the current mongod or mongos instance.

serverStatus.process¶

The process field identifies which kind of MongoDB instance is running. Possible values are:

serverStatus.uptime¶: The value of the uptime field corresponds to the number of seconds that the mongos or mongod process has been active.

serverStatus.uptimeEstimate¶: uptimeEstimate provides the uptime as calculated from MongoDB’s internal course-grained time keeping system.

serverStatus.localTime¶: The localTime value is the current time, according to the server, in UTC specified in an ISODate format.

locks¶

For an example of the locks output, see the locks section of the Server Status Output page.

serverStatus.locks¶

Changed in version 3.0.

The locks document contains embedded documents that provides a granular report for each lock type and mode. The possible lock types are as follows:

Global represents global lock.
MMAPV1Journal represents MMAPv1 storage engine specific lock to synchronize journal writes; for non-MMAPv1 storage engines, the mode for MMAPV1Journal is empty.
Database represents database lock.
Collection represents collection lock.
Metadata represents metadata lock.
oplog represents lock on the oplog.

The possible modes are as follows:

R represents Shared (S) lock.
W represents Exclusive (X) lock.
r represents Intent Shared (IS) lock.
w represents Intent Exclusive (IX) lock.

All values are of the NumberLong() type.

serverStatus.locks.acquireCount¶: Number of times the lock was acquired in the specified mode.

serverStatus.locks.acquireWaitCount¶: Number of times the acquireCount lock acquisitions encountered waits because the locks were held in a conflicting mode.

serverStatus.locks.timeAcquiringMicros¶

Cumulative wait time in microseconds for the lock acquisitions.

timeAcquiringMicros divided by acquireWaitCount gives an approximate average wait time for the particular lock mode.

serverStatus.locks.deadlockCount¶: Number of times the lock acquisitions encountered deadlocks.

globalLock¶

For an example of the globalLock output, see the globalLock section of the Server Status Output page.

serverStatus.globalLock¶: The globalLock data structure contains information regarding the database’s current lock state, historical lock status, current operation queue, and the number of active clients.

serverStatus.globalLock.totalTime¶: The value of totalTime represents the time, in microseconds, since the database last started and created the globalLock. This is roughly equivalent to total server uptime.

serverStatus.globalLock.currentQueue¶: The currentQueue data structure value provides more granular information concerning the number of operations queued because of a lock.

serverStatus.globalLock.currentQueue.total¶

The value of total provides a combined total of operations queued waiting for the lock.

A consistently small queue, particularly of shorter operations, should cause no concern. Also, consider this value in light of the size of queue waiting for the read lock (e.g. readers) and write lock (e.g. writers) individually.

serverStatus.globalLock.currentQueue.readers¶: The value of readers is the number of operations that are currently queued and waiting for the read lock. A consistently small read-queue, particularly of shorter operations, should cause no concern.

serverStatus.globalLock.currentQueue.writers¶: The value of writers is the number of operations that are currently queued and waiting for the write lock. A consistently small write-queue, particularly of shorter operations, is no cause for concern.

globalLock.activeClients¶

serverStatus.globalLock.activeClients¶

The activeClients data structure provides more granular information about the number of connected clients and the operation types (e.g. read or write) performed by these clients.

Use this data to provide context for the currentQueue data.

serverStatus.globalLock.activeClients.total¶: The value of total is the total number of active client connections to the database. This combines clients that are performing read operations (e.g. readers) and clients that are performing write operations (e.g. writers).

serverStatus.globalLock.activeClients.readers¶: The value of readers contains a count of the active client connections performing read operations.

serverStatus.globalLock.activeClients.writers¶: The value of writers contains a count of active client connections performing write operations.

mem¶

For an example of the mem output, see the mem section of the Server Status Output page.

serverStatus.mem¶: The mem data structure holds information regarding the target system architecture of mongod and current memory use.

serverStatus.mem.bits¶: The value of bits is either 64 or 32, depending on which target architecture specified during the mongod compilation process. In most instances this is 64, and this value does not change over time.

serverStatus.mem.resident¶: The value of resident is roughly equivalent to the amount of RAM, in megabytes (MB), currently used by the database process. In normal use this value tends to grow. In dedicated database servers this number tends to approach the total amount of system memory.

serverStatus.mem.virtual¶

virtual displays the quantity, in megabytes (MB), of virtual memory used by the mongod process. With journaling enabled, the value of virtual is at least twice the value of mapped.

If virtual value is significantly larger than mapped (e.g. 3 or more times), this may indicate a memory leak.

serverStatus.mem.supported¶: supported is true when the underlying system supports extended memory information. If this value is false and the system does not support extended memory information, then other mem values may not be accessible to the database server.

serverStatus.mem.mapped¶: The value of mapped provides the amount of mapped memory, in megabytes (MB), by the database. Because MongoDB uses memory-mapped files, this value is likely to be to be roughly equivalent to the total size of your database or databases.

serverStatus.mem.mappedWithJournal¶: mappedWithJournal provides the amount of mapped memory, in megabytes (MB), including the memory used for journaling. This value will always be twice the value of mapped. This field is only included if journaling is enabled.

serverStatus.mem.note¶: The field note appears if supported is false. The note field contains the text: "not all mem info support on this platform".

connections¶

For an example of the connections output, see the connections section of the Server Status Output page.

serverStatus.connections¶: The connections sub document data regarding the current status of incoming connections and availability of the database server. Use these values to assess the current load and capacity requirements of the server.

serverStatus.connections.current¶

The value of current corresponds to the number of connections to the database server from clients. This number includes the current shell session. Consider the value of available to add more context to this datum.

This figure will include all incoming connections including any shell connections or connections from other servers, such as replica set members or mongos instances.

serverStatus.connections.available¶: available provides a count of the number of unused available incoming connections the database can provide. Consider this value in combination with the value of current to understand the connection load on the database, and the UNIX ulimit Settings document for more information about system thresholds on available connections.

serverStatus.connections.totalCreated¶: totalCreated provides a count of all incoming connections created to the server. This number includes connections that have since closed.

extra_info¶

For an example of the extra_info output, see the extra_info section of the Server Status Output page.

serverStatus.extra_info¶: The extra_info data structure holds data collected by the mongod instance about the underlying system. Your system may only report a subset of these fields.

serverStatus.extra_info.note¶: The field note reports that the data in this structure depend on the underlying platform, and has the text: “fields vary by platform.”

serverStatus.extra_info.heap_usage_bytes¶: The heap_usage_bytes field is only available on Unix/Linux systems, and reports the total size in bytes of heap space used by the database process.

serverStatus.extra_info.page_faults¶

The page_faults Reports the total number of page faults that require disk operations. Page faults refer to operations that require the database server to access data which isn’t available in active memory. The page_faults counter may increase dramatically during moments of poor performance and may correlate with limited memory environments and larger data sets. Limited and sporadic page faults do not necessarily indicate an issue.

Windows draws a distinction between “hard” page faults involving disk IO, and “soft” page faults that only require moving pages in memory. MongoDB counts both hard and soft page faults in this statistic.

backgroundFlushing¶

Note

backgroundFlushing information only appears for instances that use the MMAPv1 storage engine.

For an example of the backgroundFlushing output, see the backgroundFlushing section of the Server Status Output page.

serverStatus.backgroundFlushing¶: mongod periodically flushes writes to disk. In the default configuration, this happens every 60 seconds. The backgroundFlushing data structure contains data regarding these operations. Consider these values if you have concerns about write performance and journaling.

serverStatus.backgroundFlushing.flushes¶: flushes is a counter that collects the number of times the database has flushed all writes to disk. This value will grow as database runs for longer periods of time.

serverStatus.backgroundFlushing.total_ms¶: The total_ms value provides the total number of milliseconds (ms) that the mongod processes have spent writing (i.e. flushing) data to disk. Because this is an absolute value, consider the value of flushes and average_ms to provide better context for this datum.

serverStatus.backgroundFlushing.average_ms¶

The average_ms value describes the relationship between the number of flushes and the total amount of time that the database has spent writing data to disk. The larger flushes is, the more likely this value is likely to represent a “normal,” time; however, abnormal data can skew this value.

Use the last_ms to ensure that a high average is not skewed by transient historical issue or a random write distribution.

serverStatus.backgroundFlushing.last_ms¶: The value of the last_ms field is the amount of time, in milliseconds, that the last flush operation took to complete. Use this value to verify that the current performance of the server and is in line with the historical data provided by average_ms and total_ms.

serverStatus.backgroundFlushing.last_finished¶

The last_finished field provides a timestamp of the last completed flush operation in the ISODate format. If this value is more than a few minutes old relative to your server’s current time and accounting for differences in time zone, restarting the database may result in some data loss.

Also consider ongoing operations that might skew this value by routinely block write operations.

cursors¶

Deprecated since version 2.6: See the serverStatus.metrics.cursor field instead.

For an example of the cursors output, see the cursors section of the Server Status Output page.

serverStatus.cursors¶: The cursors data structure contains data regarding cursor state and use.

serverStatus.cursors.note¶: A note specifying to use the serverStatus.metrics.cursor field instead of serverStatus.cursors.

serverStatus.cursors.totalOpen¶: totalOpen provides the number of cursors that MongoDB is maintaining for clients. Because MongoDB exhausts unused cursors, typically this value small or zero. However, if there is a queue, stale tailable cursor, or a large number of operations, this value may rise.

serverStatus.cursors.clientCursors_size¶: Deprecated since version 1.x: See totalOpen for this datum.

serverStatus.cursors.timedOut¶: timedOut provides a counter of the total number of cursors that have timed out since the server process started. If this number is large or growing at a regular rate, this may indicate an application error.

serverStatus.cursors.totalNoTimeout¶: totalNoTimeout provides the number of open cursors with the option DBQuery.Option.noTimeout set to prevent timeout after a period of inactivity.

serverStatus.cursors.pinned¶: serverStatus.cursors.pinned provides the number of “pinned” open cursors.

network¶

For an example of the network output, see the network section of the Server Status Output page.

serverStatus.network¶: The network data structure contains data regarding MongoDB’s network use.

serverStatus.network.bytesIn¶: The value of the bytesIn field reflects the amount of network traffic, in bytes, received by this database. Use this value to ensure that network traffic sent to the mongod process is consistent with expectations and overall inter-application traffic.

serverStatus.network.bytesOut¶: The value of the bytesOut field reflects the amount of network traffic, in bytes, sent from this database. Use this value to ensure that network traffic sent by the mongod process is consistent with expectations and overall inter-application traffic.

serverStatus.network.numRequests¶: The numRequests field is a counter of the total number of distinct requests that the server has received. Use this value to provide context for the bytesIn and bytesOut values to ensure that MongoDB’s network utilization is consistent with expectations and application use.

repl¶

For an example of the repl output, see the repl section of the Server Status Output page.

serverStatus.repl¶

The repl data structure contains status information for MongoDB’s replication (i.e. “replica set”) configuration. These values only appear when the current host has replication enabled.