mongodb3.2+ performance monitoring

This is the replica set mode, add an authentication parameter --authenticationDatabase
mongostat --port 20012 -uadmin -p='xxxxx' --authenticationDatabase admin
mongodb3.2+ performance monitoring
Explanation of each field:
insert/s : The official explanation is the number of objects inserted into the database per second , if it is a slave, there is * before the value, which means that the replica set operation
query/s : the number of query operations per second
update/s : the number of update operations per second
delete/s : the number of delete operations per second
getmore/s: The number of getmore operations when querying cursor (cursor)
per second command: The number of commands executed per second, two values ​​(such as 3|0) will be displayed in the master-slave system, and the sub-table represents the local|copy command
Note: within one second The number of executed commands, such as batch insertion, is only considered as one command (so it should have little meaning)
dirty: only for the WiredTiger engine, the official website explains that the cache percentage of dirty data bytes
used: only for the WiredTiger engine, the official website explains that it is in use Percentage of cache
flushes:
For WiredTiger engine: Refers to the number of checkpoint triggers during a polling interval
For MMAPv1 engine: The number of times that fsync is performed per second to write data to the hard disk
Note: Generally, it is 0, and the discontinuity will be 1. The interval between two 1s gives you a rough idea of ​​how often to flush. The flush overhead is very large. If you flush frequently, you may have to find the reason.
vsize: virtual memory usage, in MB (this is the total data in the last call of mongostat)
res: physical memory usage, in MB (this is the total data in the last invocation of mongostat)
Note: This is the same as you see with top The same as above, vsize generally does not change much, and res will rise slowly. If res often drops suddenly, check to see if there are other programs eating memory.

qr: The queue length of the client waiting to read data from the MongoDB instance
qw: The queue length of the client waiting to write data from the MongoDB instance
ar: The number of active clients performing read operations
aw: The number of live clients performing write operations
Note: if These two values ​​are very large, then the DB is blocked, and the processing speed of the DB is not as fast as the request speed. See if there are slow queries that are expensive. If the query is normal and the load is indeed heavy, you need to add the machine.
netIn: network inflow of
MongoDB instance netOut: network outflow of MongoDB instance
Note: these two fields table name network bandwidth pressure, under normal circumstances, will not Be the bottleneck
conn: The total number of open connections is the sum of qr, qw, ar, aw
Note: MongoDB creates a thread for each connection, and the creation and release of threads will also have overhead, so try to configure the startup parameters of the number of connections appropriately ,

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325000461&siteId=291194637