mongodb 长时间卡顿问题

mongo 的范围查询会锁住全库,是不是有大量并发范围查询? 比如 start_time > 7 && start_time < 10000 之类? 如果没法避免这类查询 可以把一个 collection 做成一个库

先看查询语句是不是写得不好
再看索引状态，一般是索引没建
然后是 mongostat 看看是不是 IO 过高导致

最后， mongo3 从库锁改成了 collection 锁

@lianghui 没有这样的查询啊，数据最多一个 collection 也才不到一百万，也不可能锁那么久啊
@mengzhuo mongostat 读写， io ， fault 都很低，但就是突然卡一下，突然卡一下的，

看 currentop

卡的时候看一下 iotop 哈，如果有条件， ssh 上去试一下 dd 写一个 1G 的文件，看看是不是硬盘卡了。如果是 VPS ，母鸡的其他小鸡在读取硬盘。

话说我就遇到过，有时候其他小鸡不知道在干什么，我的就盘子就不动， mongodb 就死活不返回。。。

分片迁移？

@MartinWu 看了，处于 waitForLock 状态，每次等的查询不一样
@yuchting ucloud 主机，应该是有 ssd 的吧，而且每秒写只有几十， iotop 看的时候每秒写 60 几 kB 吧，不算什么吧，日志中看很奇怪，针对主键_id 跟新已存在 key 的值也会出现长达 30 秒的，插入也会出现 20 多秒的， mongodb 不应该这么弱啊
@vietor 数据量很低的，总量才一个来 G ，不需要分片吧

@sujin190 我就是用的 mongodb ，数据量非常大，完全木有问题查询、写字段完全木有问题。用得很嗨，多次出现问题，丫的都是因为母鸡出事故。

我提供的方法细节，卡的时候，两个 ssh ，一个监控 iotop ，另外一个用 dd ， iotop 这个时候会显示出 dd 写盘子的 io ，如果这个 dd 也只有几十 kb ，那么肯定母鸡问题，如果这个时候 dd 达到百 M （ ssd 很容易达到哈），那表示 mongodb 傻逼了，从 mongodb 的日志上面入手，这个时候 mongo shell setProfilingLevel 如果是默认的话，绝对有日志输出的。一查问题就知道在哪里。

@yuchting 母机问题，这个倒还没想过，不过所有都试了还是无法解释的话，还真有可能。。
如果 mongodb 傻逼了的话，一般会有什么问题呢？

上面贴了我之前优化 mongodb 的一些笔记;主要是针对查询队列堆积,查询缓慢,优化索引方面的;

先 mark