作为实时监控mongodb的利器,mongostat绝对是一把利刃,简单好用,不过,要想仔细分析mongostat状态,还少不了深刻理解每一个监控项的意义。
# mongostat insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn set repl time *79 87 *0 *0 0 13|0 0 354g 710g 10.2g 9 0 0 0|0 0|0 9k 666k 483 c56... SEC 15:07:17
下面分析每一项的含义:
inserts/s 每秒插入次数 query/s 每秒查询次数 update/s 每秒更新次数
注:10条简单的查询可能比一条复杂的查询速度还快, 所以数值的大小,意义并不大。但至少可以知道,现在是否在处理查询,是否在插入。如果是slave,数值前往往有一个*, 代表是replicate操作
getmore/s 查询时游标(cursor)的getmore操作 command/s 每秒的命令数,在主从系统中,会显示两个值 (例如:80|0),分别代表 本地|复制 命令的个数
注:一秒内执行的命令数比如批量插入,只认为是一条命令意义不大。如果是slave,会显示两个值, local|replicated,通过这两个数值的比较,或许可以看出点问题。
flushs/s 每秒执行fsync将数据写入硬盘的次数。
注:一般都是0,或者1,通过计算两个1之间的间隔时间,可以大致了解多长时间flush一次。flush开销是很大的,如果频繁的flush,可能就要找找原因了。
mapped/s 所有的被mmap的数据量,单位是MB(这是 在mongostat 最后一次调用的总数据) vsize 虚拟内存使用量,单位MB (这是 在mongostat 最后一次调用的总数据) res 物理内存使用量,单位MB (这是 在mongostat 最后一次调用的总数据)
注:这个和你用top看到的一样,mapped, vsize一般不会有大的变动, res会慢慢的上升,如果res经常突然下降,去查查是否有别的程序狂吃内存。
faults/s 每秒访问失败数(只有Linux有),数据被交换出物理内存,放到swap。
注:不要超过100,否则就是机器内存太小,造成频繁swap写入。此时要升级内存或者扩展,大压力下这个数值往往不为0。如果经常不为0,那就该加内存了。
推荐文章:http://huoding.com/2011/08/19/107
locked % 被锁的时间百分比,尽量控制在50%以下吧
注:MongoDB就一把读写锁,这里指的是写锁所住的时间百分比。这个数值过大(经常超过10%),那就是出状况了。
idx miss % 访问加载 btree 节点时需要页面故障的尝试的索引百分比。
注:这是一个采样值。如果太高的话就要考虑索引是不是少了,非常重要的参数, 正常情况下,所有的查询都应该通过索引,也就是idx miss为0。如果这里数值较大,是不是缺少索引。
qr 客户端等待从 MongoDB 实例读取数据的队列长度。 qw 客户端等待向 MongoDB 实例写入数据的队列长度。 ar 执行读取操作的活动客户端的数目。 aw 执行写入操作的活动客户端的数目。
注:如果这两个数值很大,那么就是DB被堵住了,DB的处理速度不及请求速度。看看是否有开销很大的慢查询。如果查询一切正常,确实是负载很大,就需要加机器了。
netIn The amount of network traffic, inbytes, received by the MongoDB instance. This includes traffic from mongostat itself. netOut The amount of network traffic, inbytes, sent by the MongoDB instance. This includes traffic from mongostat itself.
注:网络带宽压力,一般MongoDB,网络不会成为瓶颈
conn 打开连接的总数。
注: MongoDB为每一个连接创建一个线程,线程的创建和释放也是有开销的。尽量不要让这个数值很大。
set 副本集的名称。 repl 节点的复制状态。
注:
M - master
SEC - secondary
REC - recovering
UNK - unknown
SLV - slave
time 时间戳
推荐文章;http://www.cnblogs.com/zhuque/archive/2013/03/29/2988577.html
转载于:https://blog.51cto.com/yucanghai/1705155