MongoDB每2小时10分钟准确地减速

在过去的3个月里,我的MongoDB服务器每2小时10分钟变得非常慢,非常准确。

我的服务器configuration:

  • 3个副本集,并且为了数据备份的目的,其中1个具有3600秒的延迟。
  • 副本集中的3个主服务器没有从服务器。
  • 使用mongoose + node.js来提供rest api。
  • 在24小时统计数据中平均每秒约有9次读和1.5次写。

searchstackoverflow和google后我做了什么

  • 重新启动服务器不能改变慢2小时10分钟的时间间隔
  • 创build索引到我查询的所有字段,没有影响
  • 在一台服务器上删除数据文件,使用另一台服务器恢复,然后删除恢复,恢复,不影响
  • 转移主服务器,没有影响
  • 当数据库运行缓慢的时候运行'currentOps',我可以看到很多查询挂在那里,太多的日志粘贴在这里,却没有看到一些exception的查询。
  • 在mongo控制台中,当数据库很慢时,检查“serverStatus”,等待数据库恢复的命令。
  • 数据库速度慢时,“top”命令没有增加内存使用量。
  • 没有访问数据库的rest api运行良好。

我猜可能有东西locking,最可能的原因是它可能是build立索引。 在我的数据库中有一些特殊东西

  • 我在一个数据库中有大约14000个集合,并且正在增加。 一个集合中可能有1到3000个logging。
  • 收集数量和数量logging都在dynamic增加。
  • 索引字段将在创build新集合时指定。

这个问题我一直沉迷了3个月。 任何意见/build议将不胜感激!

以下是我的日志文件中的一些日志

Fri Jul 5 15:20:11 .040 [conn2765] serverStatus很慢:{after basic:0,after asserts:0,after backgroundFlushing:0,after connections:0,after cursorors:0,after dur:0,after extra_info:0,在globalLock之后:0,在indexCounters:0之后,锁之后:0,之后network:0,之后opcounters:0,之后opcountersRepl:0,之后recordStats:222694,之后repl:222694,在end:222694}

星期五7月5日17:30:09 .367 [conn4711] serverStatus很慢:{后基本:0,后断言:0,后backgroundFlushing:0,后连接:0,后游标:0,后dur:0,后extra_info:0,在globalLock之后:0,在indexCounters:0之后,在锁之后:0,在network之后:0,在opcounters之后:0,在opcountersRepl:0之后,在recordStats之后:199498之后,在repl之后:199498之后,

星期五7月5日19:40:12 .697 [conn6488] serverStatus很慢:{after basic:0,after assert:0,after backgroundFlushing:0,after connections:0,after cursorors:0,after dur:0 after extra_info:0,在全局locking之后:0,在indexCounters之后:0,locking之后:0,networking之后:0,opcounters之后:0,opcounters之后:0,recordStats之后:204061,之后repl:204061,结束:204081}

这里是我的pingdom报告的屏幕截图,服务器每2小时7分钟下降4分钟。 一开始,服务器每2小时6分钟下降2分钟。 pingdom的报告

[编辑1]来自主机提供商的更多显示器结果: CPU http://i.minus.com/iZBNyMPzLSLRr.png DiskIO http://i.minus.com/ivgrHr0Ghoz92.png 连接http://i.minus.com/ itbfYq0SSMlNs.png周期性增加的连接是因为连接正在等待,并且当前连接的计数将累计,直到数据库被解除阻塞。 这不是因为巨大的stream量。

       

网上收集的解决方案 "MongoDB每2小时10分钟准确地减速"

我们发现了一个具体的2:10问题。 在我们的例子中,这是由MMS执行的dbStats。 我们不得不升级,并解决了问题。

我有类似的问题。 我会从mongostat / mongotop开始,从那里开始工作。 用mongostat识别主要的工作负载,然后找出哪个集合导致了这个活动。

对于我的具体情况,我有一个删除过时logging的cron作业。 事实certificate,副本集传播这个命令的方式是非常资源密集型的。 例如,我会从集合中删除3mlogging,这发生在副本集主上。 由于某种原因,这种传播使得所有的次级密集的工作在后续的传播中。

如果你能看到db.currentOp东西,我会把重点放在那些运行时间很长的东西上,并试图从那里消除根本原因。

希望有所帮助。

我认为你的意思是一个3节点的复制品,而不是“3副本集”。

如果你仍然遇到同样的问题。 这是我的意见:

  1. 既然你在linode.com上运行你的服务器。 您的服务器实际上是一台虚拟机,您正在与其他人共享资源。 周期性的减速可能是由于其他人周期性地运行磁盘负载。 既然你已经看了很多不同的可能性,这可能是一个select,即使它需要一点努力。

  2. 这肯定是由MongoDB或您的系统运行的作业造成的。 请尝试寻找定期运行的任何工作。 例如,尝试删除其中一个辅助节点上的3600秒延迟。 即使这不是2小时10分钟,但这可能是一个触发器。

我不能发表我的意见,因为它不允许我。 所以,我发布这个答案。