serverStatus¶

On this page

Definition
Output

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:

copy

{ 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:

copy

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

serverStatus includes all fields by default, except workingSet, by default.

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.

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¶

New in version 2.1.2: All locks statuses first appeared in the 2.1.2 development release for the 2.2 series.

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

serverStatus.locks¶

The locks document contains sub-documents that provides a granular report on MongoDB database-level lock use. All values are of the NumberLong() type.

Generally, fields named:

R refer to the global read lock,
W refer to the global write lock,
r refer to the database specific read lock, and
w refer to the database specific write lock.

If a document does not have any fields, it means that no locks have existed with this context since the last time the mongod started.

serverStatus.locks..¶: A field named . holds the first document in locks that contains information about the global lock.

serverStatus.locks...timeLockedMicros¶: The timeLockedMicros document reports the amount of time in microseconds that a lock has existed in all databases in this mongod instance.

serverStatus.locks...timeLockedMicros.R¶: The R field reports the amount of time in microseconds that any database has held the global read lock.

serverStatus.locks...timeLockedMicros.W¶: The W field reports the amount of time in microseconds that any database has held the global write lock.

serverStatus.locks...timeLockedMicros.r¶: The r field reports the amount of time in microseconds that any database has held the local read lock.

serverStatus.locks...timeLockedMicros.w¶: The w field reports the amount of time in microseconds that any database has held the local write lock.

serverStatus.locks...timeAcquiringMicros¶: The timeAcquiringMicros document reports the amount of time in microseconds that operations have spent waiting to acquire a lock in all databases in this mongod instance.

serverStatus.locks...timeAcquiringMicros.R¶: The R field reports the amount of time in microseconds that any database has spent waiting for the global read lock.

serverStatus.locks...timeAcquiringMicros.W¶: The W field reports the amount of time in microseconds that any database has spent waiting for the global write lock.

serverStatus.locks.admin¶: The admin document contains two sub-documents that report data regarding lock use in the admin database.

serverStatus.locks.admin.timeLockedMicros¶: The timeLockedMicros document reports the amount of time in microseconds that locks have existed in the context of the admin database.

serverStatus.locks.admin.timeLockedMicros.r¶: The r field reports the amount of time in microseconds that the admin database has held the read lock.

serverStatus.locks.admin.timeLockedMicros.w¶: The w field reports the amount of time in microseconds that the admin database has held the write lock.

serverStatus.locks.admin.timeAcquiringMicros¶: The timeAcquiringMicros document reports on the amount of field time in microseconds that operations have spent waiting to acquire a lock for the admin database.

serverStatus.locks.admin.timeAcquiringMicros.r¶: The r field reports the amount of time in microseconds that operations have spent waiting to acquire a read lock on the admin database.

serverStatus.locks.admin.timeAcquiringMicros.w¶: The w field reports the amount of time in microseconds that operations have spent waiting to acquire a write lock on the admin database.

serverStatus.locks.local¶: The local document contains two sub-documents that report data regarding lock use in the local database. The local database contains a number of instance specific data, including the oplog for replication.

serverStatus.locks.local.timeLockedMicros¶: The timeLockedMicros document reports on the amount of time in microseconds that locks have existed in the context of the local database.

serverStatus.locks.local.timeLockedMicros.r¶: The r field reports the amount of time in microseconds that the local database has held the read lock.

serverStatus.locks.local.timeLockedMicros.w¶: The w field reports the amount of time in microseconds that the local database has held the write lock.

serverStatus.locks.local.timeAcquiringMicros¶: The timeAcquiringMicros document reports on the amount of time in microseconds that operations have spent waiting to acquire a lock for the local database.

serverStatus.locks.local.timeAcquiringMicros.r¶: The r field reports the amount of time in microseconds that operations have spent waiting to acquire a read lock on the local database.

serverStatus.locks.local.timeAcquiringMicros.w¶: The w field reports the amount of time in microseconds that operations have spent waiting to acquire a write lock on the local database.

serverStatus.locks.<database>¶: For each additional database locks includes a document that reports on the lock use for this database. The names of these documents reflect the database name itself.

serverStatus.locks.<database>.timeLockedMicros¶: The timeLockedMicros document reports on the amount of time in microseconds that locks have existed in the context of the <database> database.

serverStatus.locks.<database>.timeLockedMicros.r¶: The r field reports the amount of time in microseconds that the <database> database has held the read lock.

serverStatus.locks.<database>.timeLockedMicros.w¶: The w field reports the amount of time in microseconds that the <database> database has held the write lock.

serverStatus.locks.<database>.timeAcquiringMicros¶: The timeAcquiringMicros document reports on the amount of time in microseconds that operations have spent waiting to acquire a lock for the <database> database.

serverStatus.locks.<database>.timeAcquiringMicros.r¶: The r field reports the amount of time in microseconds that operations have spent waiting to acquire a read lock on the <database> database.

serverStatus.locks.<database>.timeAcquiringMicros.w¶: The w field reports the amount of time in microseconds that operations have spent waiting to acquire a write lock on the <database> database.

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 creation of the globalLock. This is roughly equivalent to total server uptime.

serverStatus.globalLock.lockTime¶

The value of lockTime represents the time, in microseconds, since the database last started, that the globalLock has been held.

Consider this value in combination with the value of totalTime. If the lockTime is higher and the totalTime is smaller (relatively) then fewer operations are responsible for a greater portion of server’s use (relatively).

serverStatus.globalLock.ratio¶: Changed in version 2.2: ratio was removed. See locks.

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.

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 connection status and availability of the database server. Use these values to asses 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 the current shell connection as well as any inter-node connections to support a replica set or sharded cluster.

serverStatus.connections.available¶: available provides a count of the number of unused available connections that 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 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.

indexCounters¶

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

serverStatus.indexCounters¶: Changed in version 2.2: Previously, data in the indexCounters document reported sampled data, and were only useful in relative comparison to each other, because they could not reflect absolute index use. In 2.2 and later, these data reflect actual index use.

Changed in version 2.4: Fields previously in the btree sub-document of indexCounters are now fields in the indexCounters document.

The indexCounters data structure reports information regarding the state and use of indexes in MongoDB.

serverStatus.indexCounters.accesses¶: accesses reports the number of times that operations have accessed indexes. This value is the combination of the hits and misses. Higher values indicate that your database has indexes and that queries are taking advantage of these indexes. If this number does not grow over time, this might indicate that your indexes do not effectively support your use.

serverStatus.indexCounters.hits¶

The hits value reflects the number of times that an index has been accessed and mongod is able to return the index from memory.

A higher value indicates effective index use. hits values that represent a greater proportion of the accesses value, tend to indicate more effective index configuration.

serverStatus.indexCounters.misses¶: The misses value represents the number of times that an operation attempted to access an index that was not in memory. These “misses,” do not indicate a failed query or operation, but rather an inefficient use of the index. Lower values in this field indicate better index use and likely overall performance as well.

serverStatus.indexCounters.resets¶: The resets value reflects the number of times that the index counters have been reset since the database last restarted. Typically this value is 0, but use this value to provide context for the data specified by other indexCounters values.

serverStatus.indexCounters.missRatio¶: The missRatio value is the ratio of hits to misses. This value is typically 0 or approaching 0.

backgroundFlushing¶

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¶

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.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.

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.