引自http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb
糟糕的内存管理 - MongoDB 通过内存映射整个数据集来管理内存,将页面缓存管理和故障留给内核。更智能的方案将能够在使用前对索引进行故障处理,并更有效地处理冷/热数据的故障。结果是无法有效推断内存使用情况,并且性能不是最佳的。
我不明白他的意思。有人可以详细说明一下吗?
引自http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb
糟糕的内存管理 - MongoDB 通过内存映射整个数据集来管理内存,将页面缓存管理和故障留给内核。更智能的方案将能够在使用前对索引进行故障处理,并更有效地处理冷/热数据的故障。结果是无法有效推断内存使用情况,并且性能不是最佳的。
我不明白他的意思。有人可以详细说明一下吗?
正如@cHao 所说,这有点夸张,作者并不真正了解操作系统自己的内存管理程序有多么复杂和复杂。
这就是MongoDB没有自己的内存管理的原因,因为这样做可能会导致令人头疼的问题和其他废话。归根结底,操作系统有一个非常好的内存管理过程(甚至 Windows 也有),那么为什么不使用它而不是创建一个需要数年甚至数十年才能达到相同水平的系统呢?
更智能的方案将能够在使用前对索引进行故障处理
不确定 MongoDB 是否能读懂你的想法……
我的意思是,如果您实际上已经正确设计了您的系统并且不需要同时在 RAM 中的所有(甚至是您全部使用的那些)索引,该怎么办?
对数据进行这种先发制人的分页(非故障)听起来与良好的设置有悖常理。
如果您需要在某些时候将数据保存在 RAM 中,您可以使用touch()
http://docs.mongodb.org/manual/reference/command/touch/或者您可以在 RAM 中运行您需要的常见查询的脚本。
结果是无法有效推断内存使用情况,并且性能不是最佳的。
mongod
嗯,那个人显然从来没有真正费心使用操作系统自己的内置工具来测量他们测试中进程的页面错误和内存访问。
话虽如此,在 MongoDB 的后一版本中实际上有一个工具可以帮助计算内存使用情况:http ://docs.mongodb.org/manual/reference/command/serverStatus/#server-status-workingset