Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use mongostat in MongoDB. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Mongostat detailed explanation

Mongostat is a status detection tool that comes with mongdb and is used on the command line. It gets the current running state of mongodb at regular intervals and outputs it. If you find that the database suddenly slows down or has other problems, your first-hand operation should consider using mongostat to check the status of mongo.

Its output has the following columns:

Inserts/s inserts per second

Number of queries per second by query/s

Update/s updates per second

Number of delete/s deletions per second

Getmore/s executes getmore per second

Command/s has more commands per second than the above inserts, searches, updates and deletions, and counts other commands.

The number of times per second that flushs/s executes fsync to write data to the hard disk.

The amount of data that is mmap in mapped/s, in MB.

Vsize virtual memory usage (in MB)

Res physical memory usage (in MB)

The number of faults/s access failures per second (only Linux has), and the data is swapped out of physical memory and put into swap. Do not exceed 100. otherwise, the machine memory is too small, resulting in frequent swap writes. At this point, you need to upgrade memory or expand

The percentage of time locked% is locked up, try to keep it below 50%.

Percentage of idx miss% index misses. If it is too high, consider whether there is a lack of indexes.

Q t | r | w when Mongodb receives too many commands and the database is locked and cannot be executed, it will queue the commands. This column shows the total length of three queues, read and write, and a value of 0 indicates that the mongo is under no pressure. When there is high concurrency, the general queue value will rise.

Current number of connections to conn

Time timestamp

Use profiler

Similar to MySQL's slow log, MongoDB can monitor all slow and not slow queries.

Profiler is off by default, and you can choose to turn it all on or when there is a slow query.

> use test

Switched to db test

> db.setProfilingLevel (2)

{"was": 0, "slowms": 100, "ok": 1} / / "was" is the old setting

> db.getProfilingLevel ()

View Profile Log

> db.system.profile.find () .sort ({$natural:-1})

{"ts": "Thu Jan 29 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}.

The meaning of 3 fields

Ts: timestamp

Info: specific operation

Millis: time taken by the operation (milliseconds)

Needless to say, there are official documents here. Note that the full query may be caused by an index problem, or it may be caused by the fact that the data is not in memory and therefore read into the disk.

Use the Web console

Mongodb comes with the Web console, which is enabled by default with the data service. His port adds 1000 to the Mongodb database server port. If it is the default Mongodb data service port (Which is 27017), the corresponding Web port is 28017.

You can see this page.

All connections to the current Mongodb

Access statistics of each database and Collection, including: Reads, Writes, Queries, GetMores, Inserts, Updates, Removes

The state of the write lock

And the last few hundred lines of the log file (the default log file for mongodb installed by CentOS+10gen yum is located in / var/log/mongo/mongod.log)

You can refer to the picture above.

Db.stat ()

Get the information of the current database, such as the total number of 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

{

"version": "1.6.5"

"uptime": 7208469

"uptimeEstimate": 7138829

LocalTime: "Wed Oct 26 2011 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

"mi***atio": 3.543930204420982e-7

}

}

"backgroundFlushing": {

"flushes": 120133

"total_ms": 73235923

"average_ms": 609.6236920746173

"last_ms": 1332

Last_finished: "Wed Oct 26 2011 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

}

Areas of concern:

The current number of connections and available connections in connections has been introduced by a peer. Mongodb can't handle a maximum of 2000 connections (depending on your machine performance and business), so it doesn't make sense to set it up. If you set a reasonable value, mongodb rejects new connection requests when you reach this value, avoiding being dragged down by too many connections.

The number of misses of indexCounters:btree:misses index and the high ratio of hits should consider whether the index is established correctly. Look at my "mi***atio": 3.543930204420982e-7, it's very healthy. So the miss rate can also be seen in mongostat.

Everything else is self-explanatory, and it's not the key to checking the health of mongo.

Db.currentOp ()

Mongodb commands are usually completed quickly, but when you have a busy machine or a slower command, you can get what is currently being performed through db.currentOp ().

On machines where there is no load, this command basically returns empty

> db.currentOp ()

{"inprog": []}

The following is a sample return value from a loaded machine:

{"opid": "shard3:466404288", "active": false, "waitingForLock": false, "op": "query", "ns": "sd.usersEmails", "query": {}, "client_s": "10.121.13.8 false", "desc": "conn"}

Field names can be explained by themselves. If you find that an operation is too long and the database is stuck, you can use this command to kill him.

> this is the end of the db.killOp ("shard3:466404288") article on "how to use mongostat in MongoDB". I hope the above content can be helpful to you so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.