- Reference >
- Server Status Reference
Server Status Reference¶
On this page
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.
See also
Much of the output of serverStatus
is also
displayed dynamically by mongostat
. See the
mongostat command for more information.
For examples of the serverStatus
output, see
Server Status Output Index.
Instance Information¶
-
serverStatus.
host
¶ The
host
field contains the system’s hostname. In Unix/Linux systems, this should be the same as the output of thehostname
command.
-
serverStatus.
version
¶ The
version
field contains the version of MongoDB running on the currentmongod
ormongos
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 themongos
ormongod
process has been active.
-
serverStatus.
uptimeEstimate
¶ uptimeEstimate
provides the uptime as calculated from MongoDB’s internal course-grained time keeping system.
locks¶
New in version 2.1.2: All locks
statuses first appeared in the 2.1.2
development release for the 2.2 series.
Example
-
serverStatus.
locks
¶ The
locks
document contains sub-documents that provides a granular report on MongoDB database-level lock use. All values are of theNumberLong()
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, andw
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 inlocks
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 thismongod
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 thismongod
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 thelocal
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 thelocal
database.
-
serverStatus.locks.local.timeLockedMicros.
r
¶ The
r
field reports the amount of time in microseconds that thelocal
database has held the read lock.
-
serverStatus.locks.local.timeLockedMicros.
w
¶ The
w
field reports the amount of time in microseconds that thelocal
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 thelocal
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 thelocal
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 thelocal
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¶
Example
-
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 theglobalLock
. 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 theglobalLock
has been held.Consider this value in combination with the value of
totalTime
. MongoDB aggregates these values in theratio
value. If theratio
value is small buttotalTime
is high theglobalLock
has typically been held frequently for shorter periods of time, which may be indicative of a more normal use pattern. If thelockTime
is higher and thetotalTime
is smaller (relatively,) then fewer operations are responsible for a greater portion of server’s use (relatively.)
-
serverStatus.globalLock.
ratio
¶ -
The value of
ratio
displays the relationship betweenlockTime
andtotalTime
.Low values indicate that operations have held the
globalLock
frequently for shorter periods of time. High values indicate that operations have heldglobalLock
infrequently for longer periods of time.
globalLock.currentQueue¶
-
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.
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
).
mem¶
Example
-
serverStatus.
mem
¶ The
mem
data structure holds information regarding the target system architecture ofmongod
and current memory use.
-
serverStatus.mem.
bits
¶ The value of
bits
is either64
or32
, depending on which target architecture specified during themongod
compilation process. In most instances this is64
, 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 themongod
process. In typical deployments this value is slightly larger thanmapped
. If this value is significantly (i.e. gigabytes) larger thanmapped
, this could indicate a memory leak.With journaling enabled, the value of
virtual
is twice the value ofmapped
.
-
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 othermem
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 ofmapped
. This field is only included if journaling is enabled.
connections¶
Example
-
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 ofavailable
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 ofcurrent
to understand the connection load on the database, and the UNIX ulimit Settings document for more information about system thresholds on available connections.
extra_info¶
Example
-
serverStatus.
extra_info
¶ The
extra_info
data structure holds data collected by themongod
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
field 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. Thepage_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¶
Example
-
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.The
indexCounters
data structure reports information regarding the state and use of indexes in MongoDB.
-
serverStatus.indexCounters.
btree
¶ The
btree
data structure contains data regarding MongoDB’s btree indexes.
-
serverStatus.indexCounters.btree.
accesses
¶ accesses
reports the number of times that operations have accessed indexes. This value is the combination of thehits
andmisses
. 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.btree.
hits
¶ The
hits
value reflects the number of times that an index has been accessed andmongod
is able to return the index from memory.A higher value indicates effective index use.
hits
values that represent a greater proportion of theaccesses
value, tend to indicate more effective index configuration.
-
serverStatus.indexCounters.btree.
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.btree.
resets
¶ The
resets
value reflects the number of times that the index counters have been reset since the database last restarted. Typically this value is0
, but use this value to provide context for the data specified by otherindexCounters
values.
backgroundFlushing¶
-
serverStatus.
backgroundFlushing
¶ mongod
periodically flushes writes to disk. In the default configuration, this happens every 60 seconds. ThebackgroundFlushing
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 themongod
processes have spent writing (i.e. flushing) data to disk. Because this is an absolute value, consider the value offlushes
andaverage_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 largerflushes
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 byaverage_ms
andtotal_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¶
Example
output of the cursors fields.
-
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 cursors, or a large number of operations this value may rise.
network¶
Example
-
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 themongod
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 themongod
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 thebytesIn
andbytesOut
values to ensure that MongoDB’s network utilization is consistent with expectations and application use.
repl¶
Example
-
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 Replica Set Fundamental Concepts 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, orreplSet
value in the configuration file.See Replica Set Fundamental Concepts for more information on replication.
-
serverStatus.repl.
ismaster
¶ The value of the
ismaster
field is eithertrue
orfalse
and reflects whether the current node is the master or primary node in the replica set.See Replica Set Fundamental Concepts for more information on replication.
-
serverStatus.repl.
secondary
¶ The value of the
secondary
field is eithertrue
orfalse
and reflects whether the current node is a secondary node in the replica set.See Replica Set Fundamental Concepts for more information on replication.
-
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 ofhostname:port
.See Replica Set Fundamental Concepts for more information on replication.
opcountersRepl¶
Example
-
serverStatus.
opcountersRepl
¶ The
opcountersRepl
data structure, similar to theopcounters
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 Replica Set Fundamental Concepts 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 themongod
instance last started.
-
serverStatus.opcountersRepl.
query
¶ query
provides a counter of the total number of replicated queries since themongod
instance last started.
-
serverStatus.opcountersRepl.
update
¶ update
provides a counter of the total number of replicated update operations since themongod
instance last started.
-
serverStatus.opcountersRepl.
delete
¶ delete
provides a counter of the total number of replicated delete operations since themongod
instance last started.
replNetworkQueue¶
New in version 2.1.2.
-
serverStatus.
replNetworkQueue
¶ The
replNetworkQueue
document reports on the network replication buffer, which permits replication operations to happen in the background. This feature is internal.This document only appears on secondary members of replica sets.
-
serverStatus.replNetworkQueue.
waitTimeMs
¶ waitTimeMs
reports the amount of time that a secondary waits to add operations to network queue. This value is cumulative.
opcounters¶
Example
-
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.
-
serverStatus.opcounters.
insert
¶ insert
provides a counter of the total number of insert operations since themongod
instance last started.
-
serverStatus.opcounters.
query
¶ query
provides a counter of the total number of queries since themongod
instance last started.
-
serverStatus.opcounters.
update
¶ update
provides a counter of the total number of update operations since themongod
instance last started.
-
serverStatus.opcounters.
delete
¶ delete
provides a counter of the total number of delete operations since themongod
instance last started.
asserts¶
Example
-
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 theasserts
, you should check the log file for themongod
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 theasserts
data structure.
writeBacksQueued¶
-
serverStatus.
writeBacksQueued
¶ The value of
writeBacksQueued
istrue
when there are operations from amongos
instance queued for retrying. Typically this option is false.See also
dur¶
New in version 1.8.
Journaling¶
Example
-
serverStatus.
dur
¶ The
dur
(for “durability”) document contains data regarding themongod
’s journaling-related operations and performance.mongod
must be running with journaling for these data to appear in the output of “serverStatus
”.Note
The data values are not cumulative but are reset on a regular basis as determined by the journal group commit interval. This interval is ~100 milliseconds (ms) by default (or 30ms if the journal file is on the same file system as your data files) and is cut by 1/3 when there is a
getLastError
command pending. The interval is configurable using the--journalCommitInterval
option.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
¶ New in version 2.0.
The
compression
represents the compression ratio of the data written to the journal:
-
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 themongod
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 thetimeMS
data. Use this field to provide context to the othertimeMS
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.
recordStats¶
Example
output of the recordStats fields.
-
serverStatus.
recordStats
¶ The
recordStats
document provides fine grained reporting on page faults on a per database level.
-
serverStatus.recordStats.
accessesNotInMemory
¶ accessesNotInMemory
reflects the number of timesmongod
needed to access a memory page that was not resident in memory for all databases managed by thismongod
instance.
-
serverStatus.recordStats.
pageFaultExceptionsThrown
¶ pageFaultExceptionsThrown
reflects the number of page fault exceptions thrown bymongod
when accessing data for all databases managed by thismongod
instance.
-
serverStatus.recordStats.local.
accessesNotInMemory
¶ accessesNotInMemory
reflects the number of timesmongod
needed to access a memory page that was not resident in memory for thelocal
database.
-
serverStatus.recordStats.local.
pageFaultExceptionsThrown
¶ pageFaultExceptionsThrown
reflects the number of page fault exceptions thrown bymongod
when accessing data for thelocal
database.
-
serverStatus.recordStats.admin.
accessesNotInMemory
¶ accessesNotInMemory
reflects the number of timesmongod
needed to access a memory page that was not resident in memory for the admin database.
-
serverStatus.recordStats.admin.
pageFaultExceptionsThrown
¶ pageFaultExceptionsThrown
reflects the number of page fault exceptions thrown bymongod
when accessing data for the admin database.
-
serverStatus.recordStats.<database>.
accessesNotInMemory
¶ accessesNotInMemory
reflects the number of timesmongod
needed to access a memory page that was not resident in memory for the<database>
database.
-
serverStatus.recordStats.<database>.
pageFaultExceptionsThrown
¶ pageFaultExceptionsThrown
reflects the number of page fault exceptions thrown bymongod
when accessing data for the<database>
database.