9

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

我的服务器配置：

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

搜索stackoverflow和谷歌后我做了什么：

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

我猜可能有什么东西被锁定了，最可能的原因是它可能正在构建索引。我的数据库中有一些特别的东西：

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

我被这个问题困扰了3个月。任何意见/建议将不胜感激！

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

Fri Jul 5 15:20:11 .040 [conn2765] serverStatus 非常慢：{ 在基本：0 之后，在断言之后：0，在 backgroundFlushing 之后：0，在连接之后：0，在光标之后：0，在 dur 之后：0，之后extra_info: 0, globalLock: 0, indexCounters: 0, locks: 0, network: 0, opcounters: 0, opcountersRepl: 0, recordStats: 222694, repl: 222694, at end: 222694 }

Fri Jul 5 17:30:09 .367 [conn4711] serverStatus 非常慢：{ 在基本：0 之后，在断言之后：0，在 backgroundFlushing 之后：0，在连接之后：0，在光标之后：0，在 dur 之后：0，之后extra_info: 0, globalLock: 0, indexCounters: 0, locks: 0, network: 0, opcounters: 0, opcountersRepl: 0, recordStats: 199498, repl: 199498, at end: 199528 }

Fri Jul 5 19:40:12 .697 [conn6488] serverStatus 非常慢：{ 在基本：0 之后，在断言之后：0，在 backgroundFlushing 之后：0，在连接之后：0，在光标之后：0，在 dur 之后：0，之后extra_info: 0, globalLock: 0, indexCounters: 0, locks: 0, network: 0, opcounters: 0, opcountersRepl: 0, recordStats: 204061, repl: 204061, at end: 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 周期性增加的连接数是因为连接正在等待，当前连接的计数会累积直到数据库被解锁。这不是因为巨大的流量。

4

3 回答 3

3

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

于 2015-01-06T09:42:35.903 回答
2

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

对于我的特殊情况，我有一个删除过时记录的 cron 作业。事实证明，副本集传播此命令的方式非常耗费资源。例如，我会从一个集合中删除 3m 条记录，这发生在副本集主服务器上。出于某种原因，这种传播使所有辅助节点在后续传播中密集地工作。

如果你能在 中看到东西db.currentOp，我会专注于那些运行时间长的东西，并尝试通过从那里消除来查明根本原因。

希望有帮助。

于 2014-04-01T08:03:10.660 回答
1

我认为您的意思是具有 3 个节点的副本集，而不是“3 个副本集”。

如果您仍然遇到同样的问题。以下是我的看法：

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

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

我不能在评论中发表我的建议，因为它不允许我这样做。因此，我将其发布为答案。

于 2014-01-09T20:03:42.507 回答