我有33MB的收藏品,里面有大约33,000件物品。这在过去的一个月里一直运作良好,查询响应迅速,查询速度也不慢。该集合具有所有必需的索引,通常响应几乎是即时的(1-2ms)
今天我发现有一个主要的查询队列,请求只是没有得到处理。 Oplog正在填补而且没有清理。经过一番搜索,我发现下面的帖子提示压缩和databaseRepair。我运行修复,它解决了问题。 Ridiculously slow mongoDB query on small collection in simple but big database
我的问题是该集合可能出现什么问题,以及databaseRepair如何解决问题?有没有办法让我确保不再发生这种情况?
答案 0 :(得分:1)
这里有许多问题可能会成为一个问题,但最终如果修复/契约为您解决了问题,它会建议与存储相关的问题。以下是一些建议:
磁盘性能:确保磁盘正常运行并且没有坏扇区。如果磁盘的一部分损坏,它可能会加入访问时间,您可能会再遇到这种情况。您可能也想测试RAM模块。
碎片:在不知道您的写入配置文件的情况下,很难说,但您的收藏和索引可能在整个存储系统中碎片化。运行修复将重建它们并将它们恢复为更连续的形式,从而使您的磁盘访问时间更快,特别是如果您正在使用机械磁盘并且要访问磁盘以获取大量数据。
如果这是问题,那么您可能需要调整paddingFactor以减少将来的频率,特别是如果您的更新随着时间的推移而增加文档的大小。 (假设您正在使用MMAPv1存储)。
页面错误:我假设您可能已将系统停机以进行修复,这可能会重置您的内存/工作集。您可能希望监视硬页面错误,这些错误指示您的查询受到IO的瓶颈而不是由内存中的工作集提供服务。如果情况一直如此,那么当数据进出内存时,您的应用程序行为可能会意外更改,您可能需要添加更多RAM。