mongodb - Mongo 服务器状态 - "Resident"内存

Question

通过 mongod 启动 Mongo 后，我运行了一个耗时 300 秒的 Mongo 查询。在我的“管理员”数据库上调用 db.serverStatus() 显示 Mongo 有 resident 1 GB 内存。文档解释说“驻留”内存是 Mongo 使用的物理磁盘/RAM 的数量。

然后，我重新运行相同的查询，但耗时 8 秒。这次查看常驻内存，看到了5GB。

我相信 RAM 的大幅增加有助于解释为什么查询时间从 300 秒缩短到 8 秒，但为什么常驻内存跳得如此之快？

是否推荐某种类型的“预热”步骤来准备 Mongo 以避免 300 秒查询？

Answer 1

MongoDB 使用操作系统的 mmap 功能是有原因的。这意味着，至少在 Linux 系统上，mongodb 的内存处理是基于操作系统的一些功能，称为内存映射文件。Linux 系统中的内存在多个级别进行寻址，基本上任何程序在 32 位系统上都会看到一个总计 2GB 的地址空间，在 64 位系统上则为 128TB。这是一个虚拟地址空间，这意味着在 32/64 位上，可以使用 4kb 内存页面寻址内存量(页面是内存的单独处理部分)。这就是为什么如果您在 32 位系统上启动 mongoDB，它会发出警告，指出此类系统上的数据库只能处理 2GB 的数据。显然这个虚拟地址空间大于物理内存的数量，所以这些虚拟地址和物理地址之间存在映射。一些虚拟地址驻留在真正的物理内存中，因此它们在实际内存中，但确保这一点的算法在内核方面。在 Linux 系统上运行的程序只能处理虚拟地址，如果试图访问不在物理内存中的虚拟内存地址，则会发生页面错误(您可以在 serverStatus 命令的额外信息字段中跟踪此错误)。 (你可以找到这个 here 的简短解释)

如果虚拟地址驻留在物理内存中访问内存与内存一样快，访问当前没有物理地址的虚拟地址意味着从磁盘到内存的分页并读取内存与磁盘随机读取一样快. (这使您的情况有所不同)

在 mongoDB 中有一个命令可以强制缓存集合或索引，这个命令是 touch如果您在第一次查询之前使用此命令将数据加载到内存中，您将在第一次尝试时在 8 秒内获得结果。不幸的是，您不能真正强制操作系统将此数据始终保存在内存中，因此如果您有其他东西用完了内存，操作系统会在一段时间内调出这些数据。

如果您有足够的物理内存，mongoDB 会将所有数据和索引保存在内存中。这并不总是需要的。有一部分数据需要存储在内存中以避免大量页面错误，这就是 workingset。 .您可以使用 db.runCommand( { serverStatus: 1, workingSet: 1 } ) 检查工作集的大小命令。

你无法在操作系统级别处理分页，但如果你有足够的内存，内核通常会尽可能多地缓存内容。如果工作集适合内存，你或多或少没问题。如果某些文档确实很少访问并且没有足够的内存来保存所有内容，它们将被分页。

当您运行查询时，可能会发生几件事。索引可以覆盖，这意味着根本不会触及任何文档，如果您的查询在某种意义上是选择性的，则只会触及索引的一部分。不幸的是，很难定义内存是否足够，你唯一能做的就是监控(工作集指标是一个估计值)。可以识别内存不足的症状检查此presentation .并使用 MMS .