如何在没有缓存的情况下检查mongodb查询性能

Question

我的查询需要很长时间才能完成.我喜欢做一些性能测试但是在我检查一次(当前需要约30秒)之后,查询开始运行得更快(<1秒).我认为它必须与mongodb缓存.有没有办法禁用mongodb的缓存或其他方式我可以检查性能？

我在mongohq使用mongodb.使用Ruby on Rails编程3.以下是解释:

{"cursor"=>"BtreeCursor start_-1", "nscanned"=>5276, "nscannedObjects"=>5276, "n"=>25, "millis"=>3264, "nYields"=>0, "nChunkSkips"=>0, "isMultiKey"=>false, "indexOnly"=>false, "indexBounds"=>{"start"=>[[{"$maxElement"=>1}, {"$minElement"=>1}]]}, "allPlans"=>[{"cursor"=>"BtreeCursor attendees_count_-1", "indexBounds"=>{"attendees_count"=>[[1.7976931348623157e+308, 1]]}}, {"cursor"=>"BtreeCursor images_count_-1", "indexBounds"=>{"images_count"=>[[1.7976931348623157e+308, 2]]}}, {"cursor"=>"BtreeCursor start_-1", "indexBounds"=>{"start"=>[[{"$maxElement"=>1}, {"$minElement"=>1}]]}}, {"cursor"=>"BtreeCursor start_-1_end_-1", "indexBounds"=>{"start"=>[[{"$maxElement"=>1}, {"$minElement"=>1}]], "end"=>[[{"$maxElement"=>1}, {"$minElement"=>1}]]}}, {"cursor"=>"BtreeCursor attendees._id_1 multi", "indexBounds"=>{"attendees._id"=>[[BSON::ObjectId('4f0b621e94bb688563000007'),BSON::ObjectId('4f0b621e94bb688563000007')], [BSON::ObjectId('4f0b647d5a8c00acde05236f'), BSON::ObjectId('4f0b647d5a8c00acde05236f')], [BSON::ObjectId('4f0b647d5a8c00acde052370'), BSON::ObjectId('4f0b647d5a8c00acde052370')], [BSON::ObjectId('4f0b647d5a8c00acde052371'), BSON::ObjectId('4f0b647d5a8c00acde052371')], [BSON::ObjectId('4f0b647d5a8c00acde052372'), BSON::ObjectId('4f0b647d5a8c00acde052372')], [BSON::ObjectId('4f0b647d5a8c00acde052373') ... (lots of Object IDs)]]}}}

请注意,我不得不截断一些解释,因为它太长了.存在"大量对象ID"的地方有很多对象ID(~400).

谢谢大家

Answer 1

我想您无法阻止 Mongo 准备查询计划（这就是 mongo 的工作方式）。因此，在查询统计信息之前.. 1. 通过以下方式清除所有集合的计划缓存

>db.colllction_name.getPlanCache().clear()

2. 使用Profiler记录慢查询（参见 mongo 文档），
3. 处理查询以优化它，
4. 再次清除缓存，再次检查查询性能。

Answer 2

当您第一次运行查询时，数据集是内存映射的，但尚未分页到实际内存中，请参阅MongoDB 站点上的缓存。因此，操作系统必须将该数据集分页到内存中，然后您才能运行查询并获得结果。

因为您从磁盘（慢）分页到 RAM（快），初始运行很慢，然后，除非您有内存压力，否则该数据将保留在 RAM 中，并且对该数据集的所有后续查询都将很快.

这就是 MongoDB 的设计方式，将数据集加载到内存中的过程通常称为“预热”数据库，只有在预热（在您的情况下为第一个查询）之后，您才能获得真正的性能。

值得注意的是，您的初始查询似乎仍然需要很长时间才能返回。您应该确保它有效地使用索引。该调查的最佳起点是解释（）页面。