在具有 4 个 CPU 内核和 8GB RAM 的 64 位 Debian 6 操作系统上,我可以重现 mongostat 的问题。
每当我在后台创建索引、reIndex 甚至索引时,根据top
,CPU 负载为 40-60%,RAM 已填满 90%。在索引任务运行时,我尝试mongostat
观察 CPU 负载。立即,CPU 负载接近 100% 并阻塞。
mongostat
连接到:127.0.0.1
之后什么都没有,只有 CPU 负载达到极限,直到 Ctrl + C 停止 mongostat。几秒钟后,CPU 负载缩小到约 50%,一切都恢复正常。
以相同的行为再次尝试mongostat
...
mongodb 期待更多的 CPU 还是出了什么问题?
这里的根本问题是索引构建 - 当您构建索引时,您(默认情况下)在前台执行此操作,它会阻止所有其他操作(包括
mongostat
轮询)。此外,索引构建需要外部排序,这是计算密集型的,并且潜在的大量 IO。就您应该预期的 CPU 和 IO 命中率而言,索引的大小、键的数量和数据量将决定 - 通常,您拥有的数据越多,索引越复杂,索引的时间越长越多这个过程会很昂贵。为避免此问题,您可以将索引设置为在后台构建,但您应该注意,直到SERVER-2771的修复程序在稳定版本中可用(在编写此答案时已检查到 2.5.0),索引才会构建在辅助节点的前台(因此仍然是阻塞操作)。这就是为什么仍然需要阅读在副本集上构建索引的指南以在集合上构建大型索引。
最后,从 CPU 的角度来看,为什么
mongostat
事情会变得更糟 - 由于索引构建的阻塞操作,它可能无法成功轮询,这表现为 CPU 增加,直到你 killmongostat
。这应该很容易重现,并且(取决于 CPU 影响的级别和您使用的版本)可能会成为提交错误的理由。如果它仍然发生在后台索引构建中,如上所述,那将更加令人担忧。