mongostat是mongdb自带的状态检测工具，在命令行下使用。它会间隔固定时间获取mongodb的当前运行状态，并输出。如果你发现数据库突然变慢或者有其他问题的话，你第一手的操作就考虑采用mongostat来查看mongo的状态。

它的输出有以下几列：

• inserts/s 每秒插入次数
• query/s 每秒查询次数
• update/s 每秒更新次数
• delete/s 每秒删除次数
• getmore/s 每秒执行getmore次数
• command/s 每秒的命令数，比以上插入、查找、更新、删除的综合还多，还统计了别的命令
• flushs/s 每秒执行fsync将数据写入硬盘的次数。
• mapped/s 所有的被mmap的数据量，单位是MB，
• vsize 虚拟内存使用量，单位MB
• res 物理内存使用量，单位MB
• faults/s 每秒访问失败数（只有Linux有），数据被交换出物理内存，放到swap。不要超过100，否则就是机器内存太小，造成频繁swap写入。此时要升级内存或者扩展
• locked % 被锁的时间百分比，尽量控制在50%以下吧
• idx miss % 索引不命中所占百分比。如果太高的话就要考虑索引是不是少了
• q t|r|w 当Mongodb接收到太多的命令而数据库被锁住无法执行完成，它会将命令加入队列。这一栏显示了总共、读、写3个队列的长度，都为0的话表示mongo毫无压力。高并发时，一般队列值会升高。
• conn 当前连接数
• time 时间戳

使用profiler

类似于MySQL的slow log, MongoDB可以监控所有慢的以及不慢的查询。

Profiler默认是关闭的，你可以选择全部开启，或者有慢查询的时候开启。

查看Profile日志

3个字段的意义

• ts：时间戳
• info：具体的操作
• millis：操作所花时间，毫秒

不多说，此处有官方文档。注意，造成满查询可能是索引的问题，也可能是数据不在内存造成因此磁盘读入造成。

使用Web控制台

Mongodb自带了Web控制台，默认和数据服务一同开启。他的端口在Mongodb数据库服务器端口的基础上加1000，如果是默认的Mongodb数据服务端口(Which is 27017)，则相应的Web端口为28017

这个页面可以看到

• 当前Mongodb的所有连接
• 各个数据库和Collection的访问统计，包括：Reads, Writes, Queries, GetMores ,Inserts, Updates, Removes
• 写锁的状态
• 以及日志文件的最后几百行（CentOS+10gen yum 安装的mongodb默认的日志文件位于/var/log/mongo/mongod.log)

可以参考右边的截图

db.stat()

获取当前数据库的信息，比如Obj总数、数据库总大小、平均Obj大小等

db.serverStatus()

获取服务器的状态

需要关心的地方：

• connections 当前连接和可用连接数，听过一个同行介绍过，mongodb最大处理到2000个连接就不行了（要根据你的机器性能和业务来设定），所以设大了没意义。设个合理值的话，到达这个值mongodb就拒绝新的连接请求，避免被太多的连接拖垮。
• indexCounters:btree:misses 索引的不命中数，和hits的比例高就要考虑索引是否正确建立。你看我的”missRatio” : 3.543930204420982e-7，很健康吧。所以miss率在mongostat里面也可以看
• 其他的都能自解释，也不是查看mongo健康状况的关键，就不说明了。

db.currentOp()

Mongodb 的命令一般很快就完成，但是在一台繁忙的机器或者有比较慢的命令时，你可以通过db.currentOp()获取当前正在执行的操作。

在没有负载的机器上，该命令基本上都是返回空的

以下是一个有负载的机器上得到的返回值样例：

字段名字都能自解释。如果你发现一个操作太长，把数据库卡死的话，可以用这个命令杀死他

MongoDB Monitoring Service

MongoDB Monitoring Service(MMS)是Mongodb厂商提供的监控服务，可以在网页和Android客户端上监控你的MongoDB状况。

insert:     一秒内的插入数
query :     一秒内的查询数
update:     一秒内的更新数
delete:     一秒内的删除数

getmore:    查询时游标(cursor)的getmore操作

command:    一秒内执行的命令数

flushes:    一秒内flush的次数 一般都是0，或者1，通过计算两个1之间的间隔时间，可以大致了解多长时间flush一次。flush开销是很大的，如果频繁的flush，可能就要找找原因了。

mapped:vsize: res: 这三个和用top看到的一样，mapped, vsize一般不会有大的变动， res会慢慢的上升，如果res经常突然下降，去查查是否有别的程序狂吃内存。

faults:大压力下这个数值往往不为0。如果经常不为0，那就该加内存了。

locked: MongoDB就一把读写锁，这里指的是写锁所住的时间百分比。这个数值过大(经常超过10%)，那就是出状况了。

dx miss:非常重要的参数, 正常情况下，所有的查询都应该通过索引，也就是idx miss为0。如果这里数值较大，是不是缺少索引。

qr|qw: queue lengths for clients waiting (read|write)
ar|aw: active clients (read|write) 
如果这两个数值很大，那么就是DB被堵住了，DB的处理速度不及请求速度。看看是否有开销很大的慢查询。如果查询一切正常，确实是负载很大，就需要加机器了。

netIn: network traffic in - bits
netOut: network traffic out - bits
网络带宽压力

conn: MongoDB为每一个连接创建一个线程，线程的创建和释放也是有开销的。尽量不要让这个数值很大。

repl: 服务器当前状态
    M   - master
    SEC - secondary
    REC - recovering
    UNK - unknown
    SLV - slave

time: 当前时间

在Linux平台下，无论是64位或者32位的MongoDB默认最大连接数都是819，WIN平台不知道，估计也没有人在 WIN平台下使用MongoDB做生产环境

[ root@DELL113 mongodb-linux-i686-2.4.1 ] # mongo admin -u root -p password
MongoDB shell version: 2.4.1
connecting to: 192.168.6.42/admin
> db.serverStatus().connections
{ "current" : 1, "available" : 818, "totalCreated" : NumberLong(1) }

途中available显示818少了一个，表示空闲的。current表示已经占用了的连接数，两数一加就等于819，如果我现在在连接一个，那么available就是817，current就是2

[root@bkjia mongodb-linux-i686-2.4.1] #  ./bin/mongo 192.168.6.42
MongoDB shell version: 2.4.1
connecting to: 192.168.6.42/test
> db.serverStatus().connections
{  " current "  : 1,  " available "  : 818,  " totalCreated "  : NumberLong(1) }
> db.serverStatus().connections
{  " current "  : 2,  " available "  : 817,  " totalCreated "  : NumberLong(2) }

819个连接数对于一般的站点我认为已经够用，并且都是现连现取现断。但这个连接数也可以修改，只要在启动的时候加入--maxConns即可
服务器启动

[root@lee mongodb-linux-x86_64-2.4.1] #  ./bin/mongod --dbpath=/root/db --maxConns=2000
Wed Apr 3 11:06:21.905 [initandlisten] MongoDB starting : pid=2812 port=27017 dbpath=/root/db 64-bit host=lee
Wed Apr 3 11:06:21.957 [initandlisten] db version v2.4.1
Wed Apr 3 11:06:21.957 [initandlisten] git version: 1560959e9ce11a693be8b4d0d160d633eee75110
Wed Apr 3 11:06:21.957 [initandlisten] build info: Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen  # 1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49
Wed Apr 3 11:06:21.957 [initandlisten] allocator: tcmalloc
Wed Apr 3 11:06:21.957 [initandlisten] options: { dbpath:  " /root/db " , maxConns: 2000 }
Wed Apr 3 11:06:21.982 [initandlisten] journal dir=/root/db/journal
Wed Apr 3 11:06:21.982 [initandlisten] recover : no journal files present, no recovery needed
Wed Apr 3 11:06:22.297 [initandlisten] preallocateIsFaster=true 2.62
Wed Apr 3 11:06:22.717 [initandlisten] --maxConns too high, can only handle 819
Wed Apr 3 11:06:22.724 [initandlisten] waiting  for  connections on port 27017
Wed Apr 3 11:06:22.725 [websvr] admin web console waiting  for  connections on port 28017
Wed Apr 3 11:06:25.126 [initandlisten] connection accepted  from  192.168.4.86:53917  # 1 (1 connection now open)

查询最大连接数

[root@bkjia mongodb-linux-i686-2.4.1] #  ./bin/mongo 192.168.6.42
MongoDB shell version: 2.4.1
connecting to: 192.168.6.42/test
> db.serverStatus().connections
{  " current "  : 1,  " available "  : 818,  " totalCreated "  : NumberLong(1) }
>

发现还是819？其实是Linux默认进程能打开最大文件数有关，可以通过ulimit 解决

[root@lee mongodb-linux-x86_64-2.4.1] #  ulimit -n 2500
[root@lee mongodb-linux-x86_64-2.4.1] #  ./bin/mongod --dbpath=/root/db --maxConns=2000
Wed Apr 3 11:11:07.013 [initandlisten] MongoDB starting : pid=2930 port=27017 dbpath=/root/db 64-bit host=lee
Wed Apr 3 11:11:07.013 [initandlisten] db version v2.4.1
Wed Apr 3 11:11:07.013 [initandlisten] git version: 1560959e9ce11a693be8b4d0d160d633eee75110
Wed Apr 3 11:11:07.013 [initandlisten] build info: Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen  # 1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49
Wed Apr 3 11:11:07.013 [initandlisten] allocator: tcmalloc
Wed Apr 3 11:11:07.013 [initandlisten] options: { dbpath:  " /root/db " , maxConns: 2000 }
Wed Apr 3 11:11:07.031 [initandlisten] journal dir=/root/db/journal
Wed Apr 3 11:11:07.031 [initandlisten] recover : no journal files present, no recovery needed
Wed Apr 3 11:11:07.170 [initandlisten] waiting  for  connections on port 27017
Wed Apr 3 11:11:07.171 [websvr] admin web console waiting  for  connections on port 28017
Wed Apr 3 11:11:10.076 [initandlisten] connection accepted  from  192.168.4.86:53161  # 1 (1 connection now open)

再查看最大连接数，搞定

[root@bkjia mongodb-linux-i686-2.4.1] #  ./bin/mongo 192.168.6.42
MongoDB shell version: 2.4.1
connecting to: 192.168.6.42/test
> db.serverStatus().connections
{  " current "  : 1,  " available "  : 1999,  " totalCreated "  : NumberLong(1) }
>

关于ulimit的更多知识大家可以去网上检索检索

客户端程序通常是通过DRIVER来��接，由于每次建立链接的成本都挺高，因此都用链接池来实现，SPRING DATA MONGODB中是如下配置

mongo.dbname=cms
# 线程池的大小
mongo.connectionsPerHost=100
# 这个*mongo.connectionsPerHost则是如果链接数大于100的等待xttk数
mongo.threadsAllowedToBlockForConnectionMultiplier=4
# 等待线程的等待时间
mongo.maxWaitTime=1500
mongo.socketTimeout=1500
mongo.connectTimeout=1000
mongo.autoConnectRetry=true
mongo.socketKeepAlive=true
mongo.slaveOk=true

• autoConnectRetry simply means the driver will automatically attempt to reconnect to the server(s) after unexpected disconnects. In production environments you usually want this set to true.

• connectionsPerHost are the amount of physical connections a single Mongo instance (it's singleton so you usually have one per application) can establish to a mongod/mongos process. At time of writing the java driver will establish this amount of connections eventually even if the actual query throughput is low (in order words you will see the "conn" statistic in mongostat rise until it hits this number per app server).

  There is no need to set this higher than 100 in most cases but this setting is one of those "test it and see" things. Do note that you will have to make sure you set this low enough so that the total amount of connections to your server do not exceed

  db.serverStatus().connections.available

  In production we currently have this at 40.

• connectTimeout. As the name suggest number of milliseconds the driver will wait before a connection attempt is aborted. Set timeout to something long (15-30 seconds) unless there's a realistic, expected chance this will be in the way of otherwise succesful connection attempts. Normally if a connection attempt takes longer than a couple of seconds your network infrastructure isn't capable of high throughput.

• maxWaitTime. Number of ms a thread will wait for a connection to become available on the connection pool, and raises an exception if this does not happen in time. Keep default.

• socketTimeout. Standard socket timeout value. Set to 60 seconds (60000).

• threadsAllowedToBlockForConnectionMultiplier. Multiplier for connectionsPerHost that denotes the number of threads that are allowed to wait for connections to become available if the pool is currently exhausted. This is the setting that will cause the "com.mongodb.DBPortPool$SemaphoresOut: Out of semaphores to get db connection" exception. It will throw this exception once this thread queue exceeds the threadsAllowedToBlockForConnectionMultiplier value. For example, if the connectionsPerHost is 10 and this value is 5 up to 50 threads can block before the aforementioned exception is thrown.

  If you expect big peaks in throughput that could cause large queues temporarily increase this value. We have it at 1500 at the moment for exactly that reason. If your query load consistently outpaces the server you should just improve your hardware/scaling situation accordingly.

• readPreference. (UPDATED, 2.8+) Used to determine the default read preference and replaces "slaveOk". Set up a ReadPreference through one of the class factory method. A full description of the most common settings can be found at the end of this post

• w. (UPDATED, 2.6+) This value determines the "safety" of the write. When this value is -1 the write will not report any errors regardless of network or database errors. WriteConcern.NONE is the appropriate predefined WriteConcern for this. If w is 0 then network errors will make the write fail but mongo errors will not. This is typically referred to as "fire and forget" writes and should be used when performance is more important than consistency and durability. Use WriteConcern.NORMAL for this mode.

  If you set w to 1 or higher the write is considered safe. Safe writes perform the write and follow it up by a request to the server to make sure the write succeeded or retrieve an error value if it did not (in other words, it sends a getLastError() command after you write). Note that until this getLastError() command is completed the connection is reserved. As a result of that and the additional command the throughput will be signficantly lower than writes with w <= 0. With a w value of exactly 1 MongoDB guarantees the write succeeded (or verifiably failed) on the instance you sent the write to.

  In the case of replica sets you can use higher values for w whcih tell MongoDB to send the write to at least "w" members of the replica set before returning (or more accurately, wait for the replication of your write to "w" members). You can also set w to the string "majority" which tells MongoDB to perform the write to the majority of replica set members (WriteConcern.MAJORITY). Typicall you should set this to 1 unless you need raw performance (-1 or 0) or replicated writes (>1). Values higher than 1 have a considerable impact on write throughput.

• fsync. Durability option that forces mongo to flush to disk after each write when enabled. I've never had any durability issues related to a write backlog so we have this on false (the default) in production.

• j *(NEW 2.7+)*. Boolean that when set to true forces MongoDB to wait for a successful journaling group commit before returning. If you have journaling enabled you can enable this for additional durability. Refer to http://www.mongodb.org/display/DOCS/Journaling to see what journaling gets you (and thus why you might want to enable this flag).

ReadPreference The ReadPreference class allows you to configure to what mongod instances queries are routed if you are working with replica sets. The following options are available :

• ReadPreference.primary() : All reads go to the repset primary member only. Use this if you require all queries to return consistent (the most recently written) data. This is the default.

• ReadPreference.primaryPreferred() : All reads go to the repset primary member if possible but may query secondary members if the primary node is not available. As such if the primary becomes unavailable reads become eventually consistent, but only if the primary is unavailable.

• ReadPreference.secondary() : All reads go to secondary repset members and the primary member is used for writes only. Use this only if you can live with eventually consistent reads. Additional repset members can be used to scale up read performance although there are limits to the amount of (voting) members a repset can have.

• ReadPreference.secondaryPreferred() : All reads go to secondary repset members if any of them are available. The primary member is used exclusively for writes unless all secondary members become unavailable. Other than the fallback to the primary member for reads this is the same as ReadPreference.secondary().

• ReadPreference.nearest() : Reads go to the nearest repset member available to the database client. Use only if eventually consistent reads are acceptable. The nearest member is the member with the lowest latency between the client and the various repset members. Since busy members will eventually have higher latencies this should also automatically balance read load although in my experience secondary(Preferred) seems to do so better if member latencies are relatively consistent.

Note : All of the above have tag enabled versions of the same method which return TaggableReadPreference instances instead. A full description of replica set tags can be found here :Replica Set Tags

Linux下启动mongodb（后台方式）

mongostat详解相关推荐

1. 从命令行到IDE，版本管理工具Git详解（远程仓库创建+命令行讲解+IDEA集成使用）

   首先,Git已经并不只是GitHub,而是所有基于Git的平台,只要在你的电脑上面下载了Git,你就可以通过Git去管理"基于Git的平台"上的代码,常用的平台有GitHub.Gi ...

2. JVM年轻代，老年代，永久代详解​​​​​​​

   秉承不重复造轮子的原则,查看印象笔记分享连接↓↓↓↓ 传送门:JVM年轻代,老年代,永久代详解 速读摘要 最近被问到了这个问题,解释的不是很清晰,有一些概念略微模糊,在此进行整理和记录,分享给大家.在 ...

3. docker常用命令详解

   docker常用命令详解 本文只记录docker命令在大部分情境下的使用,如果想了解每一个选项的细节,请参考官方文档,这里只作为自己以后的备忘记录下来. 根据自己的理解,总的来说分为以下几种: Doc ...

4. 通俗易懂word2vec详解词嵌入-深度学习

   https://blog.csdn.net/just_so_so_fnc/article/details/103304995 skip-gram 原理没看完 https://blog.csdn.net ...

5. 深度学习优化函数详解（5）-- Nesterov accelerated gradient (NAG) 优化算法

   深度学习优化函数详解系列目录 深度学习优化函数详解(0)– 线性回归问题 深度学习优化函数详解(1)– Gradient Descent 梯度下降法 深度学习优化函数详解(2)– SGD 随机梯度下降 ...

6. CUDA之nvidia-smi命令详解---gpu

   nvidia-smi是用来查看GPU使用情况的.我常用这个命令判断哪几块GPU空闲,但是最近的GPU使用状态让我很困惑,于是把nvidia-smi命令显示的GPU使用表中各个内容的具体含义解释一下. ...

7. Bert代码详解（一）重点详细

   这是bert的pytorch版本(与tensorflow一样的,这个更简单些,这个看懂了,tf也能看懂),地址:https://github.com/huggingface/pytorch-pretr ...

8. CRF(条件随机场)与Viterbi(维特比)算法原理详解

   摘自:https://mp.weixin.qq.com/s/GXbFxlExDtjtQe-OPwfokA https://www.cnblogs.com/zhibei/p/9391014.html C ...

9. pytorch nn.LSTM()参数详解

   输入数据格式: input(seq_len, batch, input_size) h0(num_layers * num_directions, batch, hidden_size) c0(num ...

最新文章

1. api.533.net 文章迁移计划
2. 倒排列表求交集算法汇总
3. AttributeError: module ‘tensorflow‘ has no attribute ‘placeholder‘
4. Python pip – error: invalid command ‘bdist_wheel’
5. BitNami Redmine Stack
6. java集合——具体的集合
7. Qt图形界面编程入门(Qt的历史、Qt安装资源链接、Qt Creator简介)
8. idal 创建springboot 项目_SpringBoot教程：Maven方式创建SpringBoot项目
9. WPF仿网易云音乐系列（一、左侧菜单栏：Expander+RadioButton）
10. sql脚本过大，无法打开的解决方法
11. 【PAT乙】1047 编程团体赛 (20分)字符串，桶排序
12. [HDU5739]Fantasia(圆方树DP)
13. 【Java基础】图片压缩
14. 报错解决：ninja: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20‘ not found (required by ninja)
15. 简单常用的sql语句
16. 第十二章 采购管理 采购合同类型以及其区别 合同类型与风险分担 自制与外购分析 招标文件 工作说明书（SOW） 工作大纲 (TOR) 投标人会议 采购谈判 检查 审计 索赔管理 采购合同争议解决方式对
17. 凌恩生物明星产品：一文读懂细胞器基因组！
18. 燕山大学C++实验报告
19. Go语言使用百度翻译api
20. 彩虹物语服务器维护,红手指彩虹物语云手机使用教程_红手指彩虹物语云挂机教程_彩虹物语息屏挂机教程_红手指云手机官网...

热门文章

1. 汇集全球21位医生的经验和智慧，总结出最实用的专业建议，这些都是最值得你牢记的健康秘密~
2. Eclipse 出现none applicable问题
3. ZBRUSH 脸型特征
4. 管理者怎么提升讲话能力
5. Windows安全配置技术【转】
6. 电子计算机中的gt如何操作,GT Simulator操作手册.pdf
7. 科大讯飞/百度/阿里/腾讯(BAT)智能语音识别(ASR)性能对比选择预计价格分享
8. GridView 中下载文件
9. 边界值分析法测试用例
10. 15、渗透测试基本流程