Navigation
This version of the documentation is archived and no longer supported.

serverStatus

On this page

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

See also

Much of the output of serverStatus is also displayed dynamically by mongostat. See the mongostat command for more information.

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.

See Replication for more information on replication.

serverStatus.repl.setName

The setName field contains a string with the name of the current replica set. This value reflects the --replSet command line argument, or replSetName value in the configuration file.

See Replication for more information on replication.

serverStatus.repl.ismaster

The value of the ismaster field is either true or false and reflects whether the current node is the master or primary node in the replica set.

See Replication for more information on replication.

serverStatus.repl.secondary

The value of the secondary field is either true or false and reflects whether the current node is a secondary node in the replica set.

See Replication for more information on replication.

serverStatus.repl.primary

New in version 3.0.0.

A string in the format of "[hostname]:[port]" listing the current primary member of the replica set.

serverStatus.repl.hosts

hosts is an array that lists the other nodes in the current replica set. Each member of the replica set appears in the form of hostname:port.

See Replication for more information on replication.

serverStatus.repl.me

New in version 3.0.0.

The [hostname]:[port] combination for the current member in the replica set.

serverStatus.repl.rbid

New in version 3.0.0.

Rollback identifier. Used to determine if a rollback has happened for this mongod instance.

serverStatus.repl.slaves

New in version 3.0.0.

An array with one document for every member of the replica set that reports replication process to this member. Typically this is the primary, or secondaries if using chained replication.

To include this output you must pass the repl option to the serverStatus, as in the following:

db.serverStatus({ "repl": 1 })
db.runCommand({ "serverStatus": 1, "repl": 1 })

The content of the slaves section depends on the source of each member’s replication. This section supports internal operation and is for internal and diagnostic use only.

serverStatus.repl.slaves[n].rid

An ObjectId used as an ID for the members of the replica set. For internal use only.

serverStatus.repl.slaves[n].host

The name of the host in [hostname]:[port] format for the member of the replica set.

serverStatus.repl.slaves[n].optime

Information regarding the last operation from the oplog that the member applied, as reported from this member.

serverStatus.repl.slaves[n].memberID

The integer identifier for this member of the replica set.

opcountersRepl

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

serverStatus.opcountersRepl

The opcountersRepl data structure, similar to the opcounters data structure, provides an overview of database replication operations by type and makes it possible to analyze the load on the replica in more granular manner. These values only appear when the current host has replication enabled.

These values will differ from the opcounters values because of how MongoDB serializes operations during replication. See Replication for more information on replication.

These numbers will grow over time in response to database use. Analyze these values over time to track database utilization.

serverStatus.opcountersRepl.insert

insert provides a counter of the total number of replicated insert operations since the mongod instance last started.

serverStatus.opcountersRepl.query

query provides a counter of the total number of replicated queries since the mongod instance last started.

serverStatus.opcountersRepl.update

update provides a counter of the total number of replicated update operations since the mongod instance last started.

serverStatus.opcountersRepl.delete

delete provides a counter of the total number of replicated delete operations since the mongod instance last started.

serverStatus.opcountersRepl.getmore

getmore provides a counter of the total number of “getmore” operations since the mongod instance last started. This counter can be high even if the query count is low. Secondary nodes send getMore operations as part of the replication process.

serverStatus.opcountersRepl.command

command provides a counter of the total number of replicated commands issued to the database since the mongod instance last started.

opcounters

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

serverStatus.opcounters

The opcounters data structure provides an overview of database operations by type and makes it possible to analyze the load on the database in more granular manner.

These numbers will grow over time and in response to database use. Analyze these values over time to track database utilization.

Note

The data in opcounters treats operations that affect multiple documents, such as bulk insert or multi-update operations, as a single operation. See document for more granular document-level operation tracking.

Additionally, these values reflect received operations, and increment even when operations are not successful.

serverStatus.opcounters.insert

insert provides a counter of the total number of insert operations received since the mongod instance last started.

serverStatus.opcounters.query

query provides a counter of the total number of queries received since the mongod instance last started.

serverStatus.opcounters.update

update provides a counter of the total number of update operations received since the mongod instance last started.

serverStatus.opcounters.delete

delete provides a counter of the total number of delete operations since the mongod instance last started.

serverStatus.opcounters.getmore

getmore provides a counter of the total number of “getmore” operations since the mongod instance last started. This counter can be high even if the query count is low. Secondary nodes send getMore operations as part of the replication process.

serverStatus.opcounters.command

command provides a counter of the total number of commands issued to the database since the mongod instance last started.

command counts all commands except the write commands: insert, update, and delete.

rangeDeleter

New in version 3.0.0.

Note

The rangeDeleter data is only included in the output of serverStatus if explicitly enabled. To return the rangeDeleter, use one of the following commands:

db.serverStatus( { rangeDeleter: 1 } )
db.runCommand( { serverStatus: 1, rangeDeleter: 1 } )
serverStatus.rangeDeleter

A document that reports on the work performed by the cleanupOrphaned command and the cleanup phase of the moveChunk command.

serverStatus.rangeDeleter.lastDeleteStats

An array of documents that each report on the last operations of migration cleanup operations. At most lastDeleteStats will report data for the last 10 operations.

serverStatus.rangeDeleter.lastDeleteStats[n].deletedDocs

A counter with the number of documents deleted by migration cleanup operations.

serverStatus.rangeDeleter.lastDeleteStats[n].queueStart

A timestamp that reflects when operations began entering the queue for the migration cleanup operation. Specifically, operations wait in the queue while the mongod waits for open cursors to close on the namespace.

serverStatus.rangeDeleter.lastDeleteStats[n].queueEnd

A timestamp that reflects when the migration cleanup operation begins.

serverStatus.rangeDeleter.lastDeleteStats[n].deleteStart

A timestamp for the beginning of the delete process that is part of the migration cleanup operation.

serverStatus.rangeDeleter.lastDeleteStats[n].deleteEnd

A timestamp for the end of the delete process that is part of the migration cleanup operation.

serverStatus.rangeDeleter.lastDeleteStats[n].waitForReplStart

A timestamp that reflects when the migration cleanup operation began waiting for replication to process the delete operation.

serverStatus.rangeDeleter.lastDeleteStats[n].waitForReplEnd

A timestamp that reflects when the migration cleanup operation finished waiting for replication to process the delete operation.

security

New in version 3.0.0.

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

serverStatus.security

A document reporting security configuration and details. Only appears for mongod instances compiled with support for TLS/SSL.

serverStatus.security.SSLServerSubjectName

The subject name associated with the TLS/SSL certificate specified by net.ssl.PEMKeyPassword.

serverStatus.security.SSLServerHasCertificateAuthority

A boolean that is true when the TLS/SSL certificate specified by net.ssl.PEMKeyPassword is associated with a certificate authority. false when the TLS/SSL certificate is self-signed.

serverStatus.security.SSLServerCertificateExpirationDate

A date object object that represents the date when the TLS/SSL certificate specified by net.ssl.PEMKeyPassword expires.

storageEngine

New in version 3.0.0.

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

serverStatus.storageEngine

A document with data about the current storage engine.

serverStatus.storageEngine.name

A string that represents the name of the current storage engine.

asserts

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

serverStatus.asserts

The asserts document reports the number of asserts on the database. While assert errors are typically uncommon, if there are non-zero values for the asserts, you should check the log file for the mongod process for more information. In many cases these errors are trivial, but are worth investigating.

serverStatus.asserts.regular

The regular counter tracks the number of regular assertions raised since the server process started. Check the log file for more information about these messages.

serverStatus.asserts.warning

The warning counter tracks the number of warnings raised since the server process started. Check the log file for more information about these warnings.

serverStatus.asserts.msg

The msg counter tracks the number of message assertions raised since the server process started. Check the log file for more information about these messages.

serverStatus.asserts.user

The user counter reports the number of “user asserts” that have occurred since the last time the server process started. These are errors that user may generate, such as out of disk space or duplicate key. You can prevent these assertions by fixing a problem with your application or deployment. Check the MongoDB log for more information.

serverStatus.asserts.rollovers

The rollovers counter displays the number of times that the rollover counters have rolled over since the last time the server process started. The counters will rollover to zero after 230 assertions. Use this value to provide context to the other values in the asserts data structure.

writeBacksQueued

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

serverStatus.writeBacksQueued

The value of writeBacksQueued is true when there are operations from a mongos instance queued for retrying. Typically this option is false.

See also

writeBacks

Journaling (dur)

Note

Journaling(dur) information only appears for mongod instances that use the MMAPv1 storage engine and have journaling enabled.

For an example of the Journaling (dur) output, see the journaling section of the Server Status Output page.

serverStatus.dur

The dur (for “durability”) document contains data regarding the mongod’s journaling-related operations and performance. mongod must be running with journaling for these data to appear in the output of “serverStatus”.

MongoDB reports the data in dur based on 3 second intervals of data, collected between 3 and 6 seconds in the past.

See also

Journaling for more information about journaling operations.

serverStatus.dur.commits

The commits provides the number of transactions written to the journal during the last journal group commit interval.

serverStatus.dur.journaledMB

The journaledMB provides the amount of data in megabytes (MB) written to journal during the last journal group commit interval.

serverStatus.dur.writeToDataFilesMB

The writeToDataFilesMB provides the amount of data in megabytes (MB) written from journal to the data files during the last journal group commit interval.

serverStatus.dur.compression

The compression represents the compression ratio of the data written to the journal:

( journaled_size_of_data / uncompressed_size_of_data )
serverStatus.dur.commitsInWriteLock

The commitsInWriteLock provides a count of the commits that occurred while a write lock was held. Commits in a write lock indicate a MongoDB node under a heavy write load and call for further diagnosis.

serverStatus.dur.earlyCommits

The earlyCommits value reflects the number of times MongoDB requested a commit before the scheduled journal group commit interval. Use this value to ensure that your journal group commit interval is not too long for your deployment.

serverStatus.dur.timeMS

The timeMS document provides information about the performance of the mongod instance during the various phases of journaling in the last journal group commit interval.

serverStatus.dur.timeMS.dt

The dt value provides, in milliseconds, the amount of time over which MongoDB collected the timeMS data. Use this field to provide context to the other timeMS field values.

serverStatus.dur.timeMS.prepLogBuffer

The prepLogBuffer value provides, in milliseconds, the amount of time spent preparing to write to the journal. Smaller values indicate better journal performance.

serverStatus.dur.timeMS.writeToJournal

The writeToJournal value provides, in milliseconds, the amount of time spent actually writing to the journal. File system speeds and device interfaces can affect performance.

serverStatus.dur.timeMS.writeToDataFiles

The writeToDataFiles value provides, in milliseconds, the amount of time spent writing to data files after journaling. File system speeds and device interfaces can affect performance.

serverStatus.dur.timeMS.remapPrivateView

The remapPrivateView value provides, in milliseconds, the amount of time spent remapping copy-on-write memory mapped views. Smaller values indicate better journal performance.

serverStatus.dur.timeMS.commits

The commits value provides, in milliseconds, the amount of time spent for commits.

serverStatus.dur.timeMS.commitsInWriteLock

The commitsInWriteLock value provides, in milliseconds, the amount of time spent for commits that occurred while a write lock was held.

metrics

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

New in version 2.4.0.

serverStatus.metrics

The metrics document holds a number of statistics that reflect the current use and state of a running mongod instance.

serverStatus.metrics.commands

New in version 3.0.0.

A document that reports on the use of database commands. The fields in commands are the names of database commands and each value is a document that reports the total number of commands executed as well as the number of failed executions.

serverStatus.metrics.commands.<command>.failed

The number of times <command> failed on this mongod.

serverStatus.metrics.commands.<command>.total

The number of times <command> executed on this mongod.

serverStatus.metrics.document

The document holds a document of that reflect document access and modification patterns and data use. Compare these values to the data in the opcounters document, which track total number of operations.

serverStatus.metrics.document.deleted

deleted reports the total number of documents deleted.

serverStatus.metrics.document.inserted

inserted reports the total number of documents inserted.

serverStatus.metrics.document.returned

returned reports the total number of documents returned by queries.

serverStatus.metrics.document.updated

updated reports the total number of documents updated.

serverStatus.metrics.getLastError

getLastError is a document that reports on getLastError use.

serverStatus.metrics.getLastError.wtime

wtime is an embedded document that reports getLastError operation counts with a w argument greater than 1.

serverStatus.metrics.getLastError.wtime.num

num reports the total number of getLastError operations with a specified write concern (i.e. w) that wait for one or more members of a replica set to acknowledge the write operation (i.e. a w value greater than 1.)

serverStatus.metrics.getLastError.wtime.totalMillis

totalMillis reports the total amount of time in milliseconds that the mongod has spent performing getLastError operations with write concern (i.e. w) that wait for one or more members of a replica set to acknowledge the write operation (i.e. a w value greater than 1.)

serverStatus.metrics.getLastError.wtimeouts

wtimeouts reports the number of times that write concern operations have timed out as a result of the wtimeout threshold to getLastError.

serverStatus.metrics.operation

operation is an embedded document that holds counters for several types of update and query operations that MongoDB handles using special operation types.

serverStatus.metrics.operation.fastmod

fastmod reports the number of update operations that neither cause documents to grow nor require updates to the index. For example, this counter would record an update operation that use the $inc operator to increment the value of a field that is not indexed.

serverStatus.metrics.operation.idhack

idhack reports the number of queries that contain the _id field. For these queries, MongoDB will use default index on the _id field and skip all query plan analysis.

serverStatus.metrics.operation.scanAndOrder

scanAndOrder reports the total number of queries that return sorted numbers that cannot perform the sort operation using an index.

serverStatus.metrics.operation.writeConflicts

writeConflicts reports the total number of queries that encounted write conflicts.

serverStatus.metrics.queryExecutor

queryExecutor is a document that reports data from the query execution system.

serverStatus.metrics.queryExecutor.scanned

scanned reports the total number of index items scanned during queries and query-plan evaluation. This counter is the same as totalKeysExamined in the output of explain().

serverStatus.metrics.queryExecutor.scannedObjects

scannedObjects reports the total number of documents scanned during queries and query-plan evaluation. This counter is the same as totalDocsExamined in the output of explain().

serverStatus.metrics.record

record is a document that reports data related to record allocation in the on-disk memory files.

serverStatus.metrics.record.moves

For MMAPv1 Storage Engine, moves reports the total number of times documents move within the on-disk representation of the MongoDB data set. Documents move as a result of operations that increase the size of the document beyond their allocated record size.

serverStatus.metrics.repl

repl holds an embedded document that reports metrics related to the replication process. repl document appears on all mongod instances, even those that aren’t members of replica sets.

serverStatus.metrics.repl.apply

apply holds an embedded document that reports on the application of operations from the replication oplog.

serverStatus.metrics.repl.apply.batches

batches reports on the oplog application process on secondaries members of replica sets. See Multithreaded Replication for more information on the oplog application processes

serverStatus.metrics.repl.apply.batches.num

num reports the total number of batches applied across all databases.

serverStatus.metrics.repl.apply.batches.totalMillis

totalMillis reports the total amount of time the mongod has spent applying operations from the oplog.

serverStatus.metrics.repl.apply.ops

ops reports the total number of oplog operations applied.

serverStatus.metrics.repl.buffer

MongoDB buffers oplog operations from the replication sync source buffer before applying oplog entries in a batch. buffer provides a way to track the oplog buffer. See Multithreaded Replication for more information on the oplog application process.

serverStatus.metrics.repl.buffer.count

count reports the current number of operations in the oplog buffer.

serverStatus.metrics.repl.buffer.maxSizeBytes

maxSizeBytes reports the maximum size of the buffer. This value is a constant setting in the mongod, and is not configurable.

serverStatus.metrics.repl.buffer.sizeBytes

sizeBytes reports the current size of the contents of the oplog buffer.

serverStatus.metrics.repl.network

network reports network use by the replication process.

serverStatus.metrics.repl.network.bytes

bytes reports the total amount of data read from the replication sync source.

serverStatus.metrics.repl.network.getmores

getmores reports on the getmore operations, which are requests for additional results from the oplog cursor as part of the oplog replication process.

serverStatus.metrics.repl.network.getmores.num

num reports the total number of getmore operations, which are operations that request an additional set of operations from the replication sync source.

serverStatus.metrics.repl.network.getmores.totalMillis

totalMillis reports the total amount of time required to collect data from getmore operations.

Note

This number can be quite large, as MongoDB will wait for more data even if the getmore operation does not initial return data.

serverStatus.metrics.repl.network.ops

ops reports the total number of operations read from the replication source.

serverStatus.metrics.repl.network.readersCreated

readersCreated reports the total number of oplog query processes created. MongoDB will create a new oplog query any time an error occurs in the connection, including a timeout, or a network operation. Furthermore, readersCreated will increment every time MongoDB selects a new source for replication.

serverStatus.metrics.repl.preload

preload reports on the “pre-fetch” stage, where MongoDB loads documents and indexes into RAM to improve replication throughput.

See Multithreaded Replication for more information about the pre-fetch stage of the replication process.

serverStatus.metrics.repl.preload.docs

docs is an embedded document that reports on the documents loaded into memory during the pre-fetch stage.

serverStatus.metrics.repl.preload.docs.num

num reports the total number of documents loaded during the pre-fetch stage of replication.

serverStatus.metrics.repl.preload.docs.totalMillis

totalMillis reports the total amount of time spent loading documents as part of the pre-fetch stage of replication.

serverStatus.metrics.repl.preload.indexes

indexes is an embedded document that reports on the index items loaded into memory during the pre-fetch stage of replication.

See Multithreaded Replication for more information about the pre-fetch stage of replication.

serverStatus.metrics.repl.preload.indexes.num

num reports the total number of index entries loaded by members before updating documents as part of the pre-fetch stage of replication.

serverStatus.metrics.repl.preload.indexes.totalMillis

totalMillis reports the total amount of time spent loading index entries as part of the pre-fetch stage of replication.

serverStatus.metrics.storage.freelist.search.bucketExhausted

bucketExhausted reports the number of times that mongod has checked the free list without finding a suitably large record allocation.

serverStatus.metrics.storage.freelist.search.requests

requests reports the number of times mongod has searched for available record allocations.

serverStatus.metrics.storage.freelist.search.scanned

scanned reports the number of available record allocations mongod has searched.

serverStatus.metrics.ttl

ttl is an embedded document that reports on the operation of the resource use of the ttl index process.

serverStatus.metrics.ttl.deletedDocuments

deletedDocuments reports the total number of documents deleted from collections with a ttl index.

serverStatus.metrics.ttl.passes

passes reports the number of times the background process removes documents from collections with a ttl index.

serverStatus.metrics.cursor

New in version 2.6.

The cursor is a document that contains data regarding cursor state and use.

serverStatus.metrics.cursor.timedOut

New in version 2.6.

timedOut provides 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.metrics.cursor.open

New in version 2.6.

The open is an embedded document that contains data regarding open cursors.

serverStatus.metrics.cursor.open.noTimeout

New in version 2.6.

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

serverStatus.metrics.cursor.open.pinned

New in version 2.6.

serverStatus.metrics.cursor.open.pinned provides the number of “pinned” open cursors.

serverStatus.metrics.cursor.open.total

New in version 2.6.

total 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 cursors, or a large number of operations this value may rise.

serverStatus.metrics.cursor.open.singleTarget

New in version 3.0.0.

singleTarget reflect the total number of cursors that only target a single shard. Only mongos instances report singleTarget values.

serverStatus.metrics.cursor.open.multiTarget

New in version 3.0.0.

multiTarget reflect the total number of cursors that only target more than one shard. Only mongos instances report multiTarget values.

wiredTiger

New in version 3.0.0.

Note

wiredTiger information only appears for mongod instances that use the WiredTiger storage engine. Some of the statistics, such as serverStatus.wiredTiger.LSM, roll up for the server.

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

serverStatus.wiredTiger.uri

New in version 3.0.0.

serverStatus.wiredTiger.uri holds a string. For internal use by MongoDB.

serverStatus.wiredTiger.LSM

New in version 3.0.0.

serverStatus.wiredTiger.LSM returns statistics on the LSM (Log-Structured Merge) tree. The values reflects the statistics for all LSM trees used in this server.

serverStatus.wiredTiger.async

New in version 3.0.0.

serverStatus.wiredTiger.async returns statistics related to the asynchronous operations API. This is unused by MongoDB.

serverStatus.wiredTiger.block-manager

New in version 3.0.0.

serverStatus.wiredTiger.block-manager returns statistics on the block manager operations.

serverStatus.wiredTiger.cache

New in version 3.0.0.

serverStatus.wiredTiger.cache returns statistics on the cache and page evictions from the cache.

The size of the cache is tunable through the storage.wiredTiger.engineConfig.cacheSizeGB setting. If the cache does not have enough space to load additional data, WiredTiger evicts pages from the cache to free up space.

Note

The storage.wiredTiger.engineConfig.cacheSizeGB only limits the size of the WiredTiger cache, not the total amount of memory used by mongod. The WiredTiger cache is only one component of the RAM used by MongoDB. MongoDB also automatically uses all free memory on the machine via the filesystem cache (data in the filesystem cache is compressed).

In addition, the operating system will use any free RAM to buffer filesystem blocks.

To accommodate the additional consumers of RAM, you may have to decrease WiredTiger cache size. Avoid increasing the WiredTiger cache size above its default value.

The default WiredTiger cache size value assumes that there is a single mongod instance per node. If a single node contains multiple instances, then you should decrease the setting to accommodate the other mongod instances.

If you run mongod in a container (e.g. lxc, cgroups, Docker, etc.) that does not have access to all of the RAM available in a system, you must set storage.wiredTiger.engineConfig.cacheSizeGB to a value less than the amount of RAM available in the container. The exact amount depends on the other processes running in the container.

serverStatus.wiredTiger.connection

New in version 3.0.0.

serverStatus.wiredTiger.connection returns statistics related to WiredTiger connections.

serverStatus.wiredTiger.cursor

New in version 3.0.0.

serverStatus.wiredTiger.cursor returns statistics on WiredTiger cursor.

serverStatus.wiredTiger.data-handle

New in version 3.0.0.

serverStatus.wiredTiger.data-handle returns statistics on the data handles and sweeps.

serverStatus.wiredTiger.log

New in version 3.0.0.

serverStatus.wiredTiger.log returns statistics on WiredTiger’s write ahead log.

serverStatus.wiredTiger.reconciliation

New in version 3.0.0.

serverStatus.wiredTiger.reconciliation returns statistics on the reconciliation process.

serverStatus.wiredTiger.session

New in version 3.0.0.

serverStatus.wiredTiger.session returns the open cursor count and open session count for the session.

serverStatus.wiredTiger.thread-yield

New in version 3.0.0.

serverStatus.wiredTiger.thread-yield returns statistics on yields during page acquisitions.

serverStatus.wiredTiger.transaction

New in version 3.0.0.

serverStatus.wiredTiger.transactions returns statistics on transaction checkpoints and operations.

serverStatus.wiredTiger.concurrentTransactions

New in version 3.0.0.

serverStatus.wiredTiger.concurrentTransactions returns information on the number of concurrent transactions allowed into the WiredTiger storage engine. These settings are MongoDB-specific.

To change the settings for concurrent reads and write transactions, see wiredTigerConcurrentReadTransactions and wiredTigerConcurrentWriteTransactions.

←   hostInfo features  →