我希望 MongoDB 将查询结果保存在 RAM 中更长时间(如果内存可用，则说 30 分钟)。可能吗？或者有什么方法可以确保在后续查询之前将数据预加载到 RAM 中。
事实上，我想知道 MongoDB 的简单查询结果性能。我有一个 10GB RAM 的专用服务器，我的 db.stats() 如下；
db.stats();
{
"db": "test",
"collections":16,
"objects":625690,
"avgObjSize":68.90,
"dataSize":43061996,
"storageSize":1121402888,
"numExtents":74,
"indexes":25,
"indexSize":28207200,
"fileSize":469762048,
"nsSizeMB":16,
"ok":1
}
现在，当我从 Web 服务查询单个文档 (as mentioned here) 时，它会在 1.3 秒内加载。相同查询的后续调用会在 400 毫秒内给出响应，然后几秒钟后，它再次开始需要 1.3 秒。看起来 MongoDB 已经从内存中丢失了先前查询的文档，因为没有其他查询要求映射到 RAM 的数据。
请解释一下，让我知道如何让后续查询更快响应。
最佳答案
您在初始查询中观察到的性能问题可能是以下问题之一(按可能性的大致顺序):
1) 您的应用程序/Web 服务在第一次请求时需要初始化一些开销(即分配内存、设置连接池、解析 DNS，...)。
2) 您请求的索引或数据尚未在内存中，因此需要加载。
3) Query Optimizer在第一个请求上运行可能需要更长的时间，因为它正在比较您的查询模式的计划执行。
通过 mongo shell 测试查询会非常有帮助，并确定开销是否与 MongoDB 或您的 Web 服务有关(而不是像您所做的那样对两者进行计时)。
以下是一些与 MongoDB 相关的注意事项。
缓存
MongoDB 对内存中的文档没有“缓存”时间。它使用内存映射文件进行磁盘 I/O，内存中的文档基于您的事件查询(您最近加载的文档/索引)以及可用内存。操作系统的虚拟内存管理器负责caching ，并且通常会遵循最近最少使用 (LRU) 算法来决定哪些页面要换出内存。
内存使用
预期的行为是，随着时间的推移，MongoDB 将增长到使用所有可用内存来存储您的事件工作数据集。
查看您提供的 db.stats() 数字(并假设这是您的 only 数据库)，看起来您的数据库大小当前约为 1Gb，因此您应该能够将所有内容保存在 10Gb 总 RAM 内，除非:
- 还有其他进程在争夺内存
- 您已重新启动
mongod服务器，但尚未请求这些文档/索引
在 MongoDB 2.2 中，有一个新的 touch命令可用于在服务器重新启动后将索引或文档加载到内存中。这仅应在初始启动时用于“预热”服务器，否则您可能会无益地迫使实际的“事件”数据从内存中溢出。
例如，在 linux 系统上，您可以使用 top 命令并且应该看到:
- 虚拟字节/VSIZE 往往是整个数据库的大小
- 如果服务器没有其他进程在运行，则驻留字节/RSIZE 将是机器的总内存(这包括文件系统缓存内容)
mongod不应使用交换(因为文件是内存映射的)
您可以使用 mongostat快速查看您的 mongod 事件的工具.. 或者更有用的是，使用像 MMS 这样的服务随着时间的推移监控指标。
查询优化器
MongoDB Query Optimizer每约 1,000 次写入操作比较查询模式的计划执行情况，然后缓存“获胜”查询计划，直到下次优化器运行.. 或者您显式调用 explain()在那个查询上。
这应该是一个简单的测试:在 mongo shell 中使用 .explain() 运行您的查询并查看 ms 计时，以及索引条目和扫描的文档。 explain() 的时间不是查询运行的实际时间，因为它包括比较计划的成本。典型的执行速度会快得多..您可以在 mongod 日志中查找慢查询。
默认情况下，MongoDB 将记录所有慢于 100 毫秒的查询，因此这为寻找要优化的查询提供了一个很好的起点。您可以使用 --slowms 调整慢速 ms 值。配置选项，或使用 Database Profiler命令。
进一步阅读 MongoDB 文档:
关于performance - MongoDB 将文档预加载到 RAM 中以获得更好的性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13374342/