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

Question

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

我的服务器配置：

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

搜索stackoverflow和google后，

我做了什么：

• 重新启动服务器无法更改慢速间隔2小时10分钟
• 为我查询的所有字段创建索引，无影响
• 删除一台服务器中的数据文件并使用另一台服务器进行恢复，然后删除anohter并恢复，不会产生任何影响
• 转移主服务器，没有影响
• 当数据库运行缓慢时运行'currentOps'，我可以看到很多查询挂在那里，这里粘贴了太多日志，但没有看到一些异常查询。
• 在mongo控制台中，当数据库运行缓慢时检查“serverStatus”，命令等待数据库恢复。
• 当数据库缓慢时，“top”命令没有内存使用量增加。
• 不能访问数据库的rest api运行良好。

我猜可能存在锁定，最可能的原因是它可能正在构建索引。我的数据库中有特殊的东西：

• 我在一个数据库中有大约14000个集合，并且正在增加。一个集合中可能有1到3000条记录。
• 集合数量和数量记录都在动态增加。
• 创建新集合时将指定索引字段。

我被这个问题困扰了3个月。任何意见/建议将受到高度赞赏！

以下是我日志文件中的部分日志：

  

7月5日星期五 15:20:11 .040 [conn2765] serverStatus非常慢：{基本后：0，断言后：0，后面是backgroundFlushing：0，后连接：0，之后游标：0，经过dur：0，经过extra_info：0，经过globalLock：0，经过indexCounters：0，经过lock：0，经过网络：0，经过opcounters：0，经过opcountersRepl：0，经过recordStats：222694之后，之后repl：222694，最后：222694}

     

7月5日星期五 17:30:09 .367 [conn4711] serverStatus非常慢：{基本后：0，断言后：0，后面的backgroundFlushing：0，后连接：0，之后游标：0，经过dur：0，经过extra_info：0，经过globalLock：0，经过indexCounters：0，经过lock：0，经过网络：0，经过opcounters：0，经过opcountersRepl：0，经过recordStats：199498之后，之后repl：199498，结尾：199528}

     

7月5日星期五 19:40:12 .697 [conn6488] serverStatus非常慢：{基本后：0，断言后：0，后面的backgroundFlushing：0，连接后：0，之后游标：0，经过dur：0，经过extra_info：0，经过globalLock：0，经过indexCounters：0，经过lock：0，经过网络：0，经过opcounters：0，经过opcountersRepl：0，经过recordStats：204061之后，之后repl：204061，结尾：204081}

以下是我的pingdom报告的屏幕截图，服务器每2小时7分钟缩短4分钟。在开始时，服务器每2小时6分钟下降2分钟。

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

Answer 1

我们发现了一个特定的2:10问题。在我们的例子中，它是由MMS执行的dbStats。 我们必须升级cluter，问题得到解决。

Answer 2

我遇到了类似的问题。我从mongostat / mongotop开始，从那里开始工作。使用mongostat确定主要工作负载，然后找出导致该活动的集合。

对于我的特定情况，我有一个删除过时记录的cron作业。事实证明，副本集传播此命令的方式非常耗费资源。例如，我将删除集合中的3m记录，这些记录发生在副本集主服务器上。出于某种原因，这种传播使得所有辅助设备在后续传播中都能够集中精力。

如果你能看到db.currentOp中的内容，我会专注于那些运行时间较长的内容，并尝试通过消除来确定根本原因。

希望有所帮助。

Answer 3

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

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

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

2. 这肯定是由mongodb或您的系统运行的作业引起的。请尝试寻找经常运作的任何工作。例如，尝试删除其中一个辅助设备上的3600秒延迟。即使这不是2小时10分钟，但这可能是它的触发器。

我不能在评论中发表我的建议，因为它不允许我这样做。所以，我发布这个作为答案。