The purpose of this article is to let you know how to understand the health of the mongdb you are running.
Mongostat detailed
Mongostat is a mongdb state detection tool that is used at the command line. It takes a fixed time to get the current running state of the MongoDB and outputs it. If you find that the database suddenly slows down or has other problems, your first-hand actions consider using Mongostat to view the status of the MONGO.
Its output has the following columns:
1.INSERTS/S number of inserts per second
2.QUERY/S number of queries per second
3.UPDATE/S Number of updates per second
4.DELETE/S number of deletes per second
5.GETMORE/S number of Getmore performed per second
6.COMMAND/S number of commands per second, more than insert, find, UPDATE, delete the combination of more, but also statistics of other orders
7.FLUSHS/S the number of times per second that Fsync writes data to the hard disk.
8.MAPPED/S all the amount of data that is mmap, in megabytes,
9.vsize virtual memory usage, per MB
10.res physical memory usage, per MB
11.FAULTS/S the number of access failures per second (only Linux), the data is swapped out of physical memory, and put to swap. Do not exceed 100, otherwise the machine memory is too small, causing frequent swap writes. To upgrade the memory or extend it at this time
% 12.locked% of time locked, try to keep under 50%.
The percentage of 13.idx Miss% index misses. If it's too high, consider whether the index is missing.
14.Q t|r|w When MongoDB receives too many commands and the database is locked and cannot be completed, it joins the command into the queue. This column shows the total, read, and write 3 queues of length, all of the 0 words indicate MONGO no pressure. When concurrency is high, the general queue value is elevated.
15.conn Current number of connections
16.time time Stamp
Using Profiler
Like MySQL's slow log, MongoDB can monitor all slow and slow queries.
Profiler is turned off by default, you can choose to turn it all on, or when you have a slow query.
> Use test
Switched to DB test
> Db.setprofilinglevel (2);
{"was": 0, "slowms": +, "OK": 1}//"was" are the old setting
> Db.getprofilinglevel ()
2
View Profile Log
> Db.system.profile.find (). Sort ({$natural:-1})
{"TS": "Thu 2009 15:19:32 GMT-0500 (EST)", "info":
"Query test. $cmd ntoreturn:1 reslen:66 nscanned:0 query: {profile:2} nreturned:1 bytes:50",
"Millis": 0}
3 The meaning of a field
1.ts: Time stamp
2.info: Specific operation
3.millis: The time taken by the operation, MS
Not much, there are official documents here. Note that the full query may be an index problem, or it may be that the data is not in memory and therefore disk read.
Using the Web Console
The MongoDB has its own web console, and the default and data services are opened together. His port is based on the MONGODB database server port plus 1000, and if the default MongoDB data service port (Which is 27017), the corresponding web port is 28017
This page can be seen
1. All connections to current MongoDB
2. Access statistics for various databases and collection, including: reads, writes, Queries, Getmores, inserts, Updates, removes
3. Write the lock status
4. And the last hundreds of lines of the log file (Centos+10gen Yum installed MongoDB The default log file is located in/var/log/mongo/mongod.log)
You can refer to the screenshot on the right
Db.stat ()
Gets information about the current database, such as total obj, total database size, average obj size, etc.
> Use test
Switched to DB test
> Db.stats ()
{
"Collections": 9,
"Objects": 4278845,
"Avgobjsize": 224.56603031892953,
"DataSize": 960883236,
"Storagesize": 1195438080,
"Numextents": 59,
"Indexes": 13,
"Indexsize": 801931264,
"FileSize": 6373244928,
"OK": 1
}
Db.serverstatus ()
Get the status of the server
code as follows:
{
"Version": "1.6.5",
"Uptime": 7208469,
"Uptimeestimate": 7138829,
"LocalTime": "Wed Oct 22:23:07 gmt+0800 (CST)",
"GlobalLock": {
"TotalTime": 7208469556704,
"Locktime": 4959693717,
"Ratio": 0.000688036992871448,
"Currentqueue": {
"Total": 0,
"Readers": 0,
"Writers": 0
}
},
"Mem": {
"Bits": 64,
"Resident": 3131,
"Virtual": 6172,
"Supported": TRUE,
"Mapped": 4927
},
"Connections": {
"Current": 402,
"Available": 2599
},
"Extra_info": {
"Note": "Fields vary by platform",
"Heap_usage_bytes": 832531920,
"Page_faults": 8757
},
"Indexcounters": {
"Btree": {
"Accesses": 2821726,
"Hits": 2821725,
"Misses": 1,
"Resets": 0,
"Missratio": 3.543930204420982e-7
}
},
"Backgroundflushing": {
"Flushes": 120133,
"Total_ms": 73235923,
"Average_ms": 609.6236920746173,
"Last_ms": 1332,
"last_finished": "Wed Oct 22:22:23 gmt+0800 (CST)"
},
"Cursors": {
"Totalopen": 0,
"Clientcursors_size": 0,
"TimedOut": 238392
},
"Repl": {
' IsMaster ': true
},
"Opcounters": {
"Insert": 269351,
"Query": 19331151,
"Update": 14199331,
"Delete": 1,
"Getmore": 145575,
"Command": 55982302
},
"asserts": {
"Regular": 0,
"Warning": 0,
"MSG": 0,
"User": 27,
"Rollovers": 0
},
"OK": 1
}
Places to be concerned:
1.connections the current connection and the number of available connections, heard a peer introduced, MongoDB maximum processing to 2000 of the connection is not (to be based on your machine performance and business to set), so set a big meaningless. If you set a reasonable value, you reach this value and MongoDB the new connection request to avoid being dragged down by too many connections.
2.indexcounters:btree:misses index of the number of misses, and the ratio of hits to consider whether the index is correctly established. You see my "missratio": 3.543930204420982e-7, very healthy bar. So the miss rate can also be seen in Mongostat.
3. Other explanations are not the key to looking at MONGO's health.
Db.currentop ()
Mongodb commands are usually done quickly, but you can get the currently executing operation on a busy machine or a slow command by Db.currentop ().
On a machine that is not loaded, the command basically returns an empty
Copy Code code as follows:
> Db.currentop ()
{"InProg": []}
The following is an example of a return value obtained on a loaded machine:
{"Opid": "shard3:466404288", "active": false, "Waitingforlock": False, "OP": "Query", "ns": "Sd.usersemails", "Query ": {}," client_s ":" 10.121.13.8:34473 "," desc ":" Conn "},
Field names can be explained by themselves. If you find that an operation is too long to get the database stuck, you can kill him with this command.
> Db.killop ("shard3:466404288")
MongoDB Monitoring Service
The MongoDB Monitoring Service (MMS) is a MongoDB vendor-provided monitor that monitors your MongoDB status on Web pages and Android clients.