MongoDB 查询分析

以上的 explain() 查询返回如下结果：

{ "cursor" : "BtreeCursor gender_1_user_name_1", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 0, "nscanned" : 1, "nscannedObjectsAllPlans" : 0, "nscannedAllPlans" : 1, "scanAndOrder" : false, "indexOnly" : true, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "indexBounds" : { "gender" : [ [ "M", "M" ] ], "user_name" : [ [ { "$minElement" : 1 }, { "$maxElement" : 1 } ] ] }}

现在，我们看看这个结果集的字段：

虽然MongoDB查询优化器一般工作的很不错，但是也可以使用hints来强迫MongoDB使用一个指定的索引。

这种方法某些情形下会提升性能。 一个有索引的collection并且执行一个多字段的查询(一些字段已经索引了)。

如下查询实例指定了使用 gender 和 user_name 索引字段来查询：

>db.users.find({gender:"M"},{user_name:1,_id:0}).hint({gender:1,user_name:1})

可以使用 explain() 函数来分析以上查询：

>db.users.find({gender:"M"},{user_name:1,_id:0}).hint({gender:1,user_name:1}).explain()

MongoDB 查询分析

标签：

小编还为您整理了以下内容，可能对您也有帮助：

mongoDB应用篇-mongo聚合查询

如果我们在日常操作中，将部分数据存储在了MongoDB中，但是有需求要求我们将存储进去的文档数据，按照一定的条件进行查询过滤，得到想要的结果便于二次利用，那么我们就可以尝试使用MongoDB的聚合框架。

前面我们在学习文档查询的过程中，也介绍过一些查询的操作符，其中就有一部分是简单的查询聚合函数，例如 count 、 distinct 、 group 等，如果是简单的数据分析过滤，完全可以使用这些自带的聚合函数以及查询的操作符来完成文档的过滤查询操作

如果我们遇到了一些数据需要跨多个文本或者统计等操作，这个时候可能文档自身也较为复杂，查询操作符已经无法满足的时候，这个时候就需要使用MongoDB的聚合查询框架了。

使用聚合框架可以对集合中的文档进行变换和组合查询，基本上我们使用的时候，都是使用多个构件创建一个管道，用于对一连串的文档进行处理。这里的构件包括 筛选(filter) 、 投射(projecting) 、 分组(grouping) 、 排序(sorting) 、 (limiting) 以及 跳过(skipping)

MongoDB中需要使用聚合操作，一般使用 aggregate 函数来完成多个聚合之间的连接，aggregate() 方法的基本语法格式如下 :

现在假设我们有个集合articles，里面存储了文章的集合，大致如下:

但这时我们需要查询出来每一个作者写的文章数量，需要使用aggregate()计算 ，大致如下：

输出的结果为:

通过这个简单的案例我们就能输出想要的数据和属性名，大概分析一下刚刚的聚合查询语句， by_user字段进行分组，代表每个用户一条数据，而num_tutorial则是定义了数值类型计算的结果字段，$sum则是计算总和，相当于每个用户出现一次，都会+1，最终计算出来的总和通过num_tutorial字段进行输出

注：如果管道没有给出预期的结果，就需要进行调试操作，调试的时候，可以尝试先给一个管道操作符的条件，如果这个时候查询出来的结果是我们想要的，那么我们需要再去指定第二个管道操作符，依次操作，最后就会定位到出了问题的操作符

前面我们提到聚合查询会使用管道操作符，而每一个操作符就会接受一连串的文档，对这些文档进行一些类型转换，最后将转换以后的文档结果传递给下一个管道操作符来执行后续的操作，如果当前是最后一个管道操作符，那么则会显示给用户最后的文档数据。不同的管道操作符是可以按照顺序组合在一起使用，并且可以被重复执行多次，例如我们可以先使用$match然后再去、 match操作。

match管道操作符可以使用$gt、$lt、$in等操作符，进行过滤，不过需要注意的是不能在$match管道操作符中使用空间地理操作符。

在实际使用的过程中，尽可能的将 match操作符以后，再去投射或者执行分组操作的话，是可以利用索引的。

相比较一般的查询操作而言，使用管道操作，尤其是其中的投射操作更加强大。我们可以在查询文档结束以后利用 $project 操作符从文档中进行字段的提取，甚至于我们可以重命名字段，将部分字段映射成我们想要展示出去的字段，也可以对一部分字段进行一些有意义的处理。需要注意的是， $project 操作符可以传入两个参数，第一个是需要处理的属性名称，第二个则是0或者1，如果传入1，则代表当前的属性是需要显示出来的，如果是0或者不写，默认都是代表这个字段不需要显示出来

当然第二个参数也可以是一个表达式或者查询条件，满足当前表达式的数据也可以进行显示，接下来我们先准备一点数据:

接下来，我们来查询，条件是item字段为abc，quantity要大于5，并且我们只要item和price字段的结果，其他都排除掉:

可以看到结果为:

如果我们想要在原基础上改变某个字段的名称，例如将item改为item_code,可以利用$来完成，如下:

可以看到我们指定的名称item_code，而这个别名对应的字段item使用$作为前缀标记，代表将item字段映射为item_code,可以看到结果:

我们在投影的时候，除了可以将某个字段映射成其他字段以外，还可以针对某个字段进行一些简单的运算，最常见的就是 四则运算 ，即

加法（ subtract ）、乘法（ divide ）、求模（ $mod ） ，

除此之外，还支持对字段进行 关系运算 (大小比较（ " eq" ）、大于（ " gte" ）、小于（ " lte" ）、不等于（ " ifNull" ） )、

逻辑运算 （与（ " or" ）、非 （ " concat" ）、截取（ " toLower" ） )等

我们基于上面的需求，假设每一个价格是按照元为单位，现在要求输出W为单位，那么我们就需要对price进行除法运算,如下:

除此之外，我们也可以将计算完毕的price改名为priceW，即:

可以看到输出的结果为:

这时有一个需求，要求我们返回数据的同时还要yyyy-MM-dd格式的时间字符串，这个时候我们就需要对date字段进行时间函数和字符串混合处理了,如下:

这里需要注意的一点是， year:" substr函数将date字段的结果截取成字符串即可实现拼接

group的_id上，代表按照当前字段进行分组，例如，我们这里根据item进行分组:

在我们针对某个字段进行分组以后，我们可以针对每个分组进行一些操作符的使用，常见的例如: $sum 、 $avg 、 $min 、 $max 、 $first 、 $last 。

$avg 操作符用来返回每一个分组内的平均值

现在我们基于前面item的分组，我们想要算出来每个组内的平均价格是多少，如下:

$min 和 $max 操作符用于返回分组内最大的值和最小的值

除了平均值以外，我们现在将最贵的和最便宜的价格也要列出来，这个时候就可以使用这两个操作符了，如下:

$first 、 $last 则是可以获取当前分组中第一个或者最后一个的某个字段的结果，如下:

除此之外，我们还可以在分组的时候使用数组操作符，例如 $addToSet 可以判断，当前数组如果不包含某个条件，就添加到当前数组中， $push 则不管元素是否存在，都直接添加到数组中

注意：大部分管道操作符都是流式处理的，只要有新的文档进入，就可以对新的文档进行处理，但是 $group 代表必须收到全部文档以后才可以进行分组操作，才会将结果传递给后续的管道操作符，这就意味着，如果当前mongo是存在分片的，会先在每个分片上执行完毕以后，再把结果传递mongos进行统一的分组，剩下的管道操作符也不会在每个分片，而是mongos上执行了

如果我们现在遇到一些文档比较复杂，比如存在内嵌文档的存在，某个属性里面嵌套了一个数组，但是我们需要对内嵌的数组文档进行分析过滤等查询处理，这个时候就可以使用 $unwind 操作符将每一个文档中的嵌套数组文件拆分为一个个的文档便于进行后续的处理,例如我们需要将之前的set集合中关于请求的url以及ip的信息拆分出来，原始的格式如下:

我们可以使用命令进行拆分，如下:

结果为:

可以看到数据则是按照每一条信息的方式展示出来了，方便后续的计算以及输出，但是需要注意的一点是，这种方式，如果该文档中没有拆分的字段，或者是空数组，默认会直接排除，如果我们需要空数组等也输出计算出来，则可以指定 preserveNullAndEmptyArrays 参数，设置为true，则代表空数组或者不存在的文档也要拆分输出出来，即:

我们可以在管道查询的过程中，按照某个属性值或者多个属性的结果进行顺序排序，排序的方式与普通查询操作符中的sort操作符表现一致，与其他管道操作符一样，可以在任何阶段使用，但是，需要注意的一点是，建议在管道操作符第一阶段进行排序，因为此时的排序是可以触发索引的，如果在后续阶段进行排序，会消耗大量内存，并且耗时会很久，尤其是在有 $group 的情况下，如果放在 $group 操作符后面，会发现等到的时间很久，不仅仅是无法触发索引的问题，还和 $group 操作符是等待所有数据完毕才会触发的特性有关，因此需要格外注意。

结果如下，按照我们想要的结果进行了排序:

limit，只返回前两条数据，如下:

结果如下:

除了 skip，与之前的查询操作符作用也是一样的，用于在已经查询完毕的结果集中跳过前N条数据以后进行返回，我们将$skip加在刚刚的查询后面，如下:

这个时候可以看到返回的结果为空，什么结果都没有了，这是因为前一步管道已经了仅仅返回2条，而接着我们又跳过了前两条文档，因此返回的结果为空，我们将顺序调换一下，看看:

可以看到结果如下，与刚才的结果无异:

管道查询操作符有很多，除了上面学习的常用的部分，还有几十个，需要了解全部的可以参考官网:

https://docs.mongodb.com/manual/reference/command/aggregate/

除此之外，我们在学习的过程中了解到，部分查询操作符是可以触发索引的，例如 $project 、 $group 或者 $unwind 操作符，因此我们也建议 如果可以的话，尽量先使用这类管道操作符进行数据过滤，可以有效减少数据集大小和数量，而且管道如果不是直接从原先的集合中使用数据，那就无

法在筛选和排序中使用索引 ，例如我们先进行管道操作，再去将过滤好的数据进行 $sort 排序，会导致无法使用索引，效率大幅度下降，因此如果我们需要涉及到 $sort 操作的时候，如果可以尽可能在最开始就处理，这个时候可以使用索引，效率较高，然后再去进行管道查询筛选与分组等其他操作，可以有效的提高查询的效率。另外需要注意的一点是，在 MongoDB中会对每一个管道查询做，例如某一步管道查询操作导致内存占用超过20%，这个时候就会报错，无法继续使用管道 ，因为mongoDB本身每次最大是16Mb的数据量，为了尽可能避免或者减少这种问题，建议可以考虑尽可能的使用 $match 操作符过滤无用数据，减少数据总大小。同时也 因为管道查询是多步执行，例如 $group 则是等待所有数据完毕才会执行，因此可能会导致整体执行时间较久 ，也因为这样，才不建议在较高的实时查询需求上使用管道和查询，而是在 设计的时候尽可能直接使用查询操作符进行数据查询，触发更多的索引，更快的销量查询出来想要的结果。

MongoDB应用1——日志分析

线上运行的服务会产生大量的运行及访问日志，日志里会包含一些错误、警告、及用户行为等信息。通常服务会以文本的形式记录日志信息，这样可读性强，方便于日常定位问题。但当产生大量的日志之后，要想从大量日志里挖掘出有价值的内容，则需要对数据进行进一步的存储和分析。

本文以存储 web 服务的访问日志为例，介绍如何使用 MongoDB 来存储、分析日志数据，让日志数据发挥最大的价值。本文的内容同样适用于其他的日志存储型应用。

一个典型的web服务器的访问日志类似如下，包含访问来源、用户、访问的资源地址、访问结果、用户使用的系统及浏览器类型等。

最简单存储这些日志的方法是，将每行日志存储在一个单独的文档里，每行日志在MongoDB里的存储模式如下所示：

上述模式虽然能解决日志存储的问题，但这些数据分析起来比较麻烦，因为文本分析并不是MongoDB所擅长的，更好的办法是把一行日志存储到MongoDB的文档里前，先提取出各个字段的值。如下所示，上述的日志被转换为一个包含很多个字段的文档。

同时，在这个过程中，如果您觉得有些字段对数据分析没有任何帮助，则可以直接过滤掉，以减少存储上的消耗。比如数据分析不会关心user信息、request、status信息，这几个字段没必要存储。ObjectId里本身包含了时间信息，没必要再单独存储一个time字段 (当然带上time也有好处，time更能代表请求产生的时间，而且查询语句写起来更方便，尽量选择存储空间占用小的数据类型）基于上述考虑，上述日志最终存储的内容可能类似如下所示：

日志存储服务需要能同时支持大量的日志写入，用户可以定制writeConcern来控制日志写入能力，比如如下定制方式：

同时，为了达到最优的写入效率，用户还可以考虑批量的写入方式，一次网络请求写入多条日志。格式如下所示：

db.events.insert([doc1, doc2, ...])

当日志按上述方式存储到MongoDB后，就可以按照各种查询需求查询日志了。

q_events = db.events.find({'path': '/apache_pb.gif'})

如果这种查询非常频繁，可以针对path字段建立索引，提高查询效率：

db.events.createIndex({path: 1})

通过对time字段建立索引，可加速这类查询：

db.events.createIndex({time: 1})

同样，用户还可以使用MongoDB的aggregation、maprece框架来做一些更复杂的查询分析，在使用时应该尽量建立合理的索引以提升查询效率。

当写日志的服务节点越来越多时，日志存储的服务需要保证可扩展的日志写入能力以及海量的日志存储能力，这时就需要使用MongoDB sharding来扩展，将日志数据分散存储到多个shard，关键的问题就是shard key的选择。

使用时间戳来进行分片（如ObjectId类型的_id，或者time字段），这种分片方式存在如下问题：

按照_id字段来进行hash分片，能将数据以及写入都均匀都分散到各个shard，写入能力会随shard数量线性增长。但该方案的问题是，数据分散毫无规律。所有的范围查询（数据分析经常需要用到）都需要在所有的shard上进行查找然后合并查询结果，影响查询效率。

假设上述场景里 path 字段的分布是比较均匀的，而且很多查询都是按path维度去划分的，那么可以考虑按照path字段对日志数据进行分片，好处是：

不足的地方是：

当然上述不足的地方也有办法改进，方法是给分片key里引入一个额外的因子,比如原来的shard key是 {path: 1}，引入额外的因子后变成：

{path: 1, ssk: 1} 其中ssk可以是一个随机值，比如_id的hash值，或是时间戳，这样相同的path还是根据时间排序的

这样做的效果是分片key的取值分布丰富，并且不会出现单个值特别多的情况。上述几种分片方式各有优劣，用户可以根据实际需求来选择方案。

分片的方案能提供海量的数据存储支持，但随着数据越来越多，存储的成本会不断的上升。通常很多日志数据有个特性，日志数据的价值随时间递减。比如1年前、甚至3个月前的历史数据完全没有分析价值，这部分可以不用存储，以降低存储成本，而在MongoDB里有很多方法支持这一需求。

MongoDB的TTL索引可以支持文档在一定时间之后自动过期删除。例如上述日志time字段代表了请求产生的时间，针对该字段建立一个TTL索引，则文档会在30小时后自动被删除。

db.events.createIndex( { time: 1 }, { expireAfterSeconds: 108000 } )

如果对日志保存的时间没有特别严格的要求，只是在总的存储空间上有*，则可以考虑使用capped collection来存储日志数据。指定一个最大的存储空间或文档数量，当达到阈值时，MongoDB会自动删除capped collection里最老的文档。

db.createCollection("event", {capped: true, size: 104857600000}

比如每到月底就将events集合进行重命名，名字里带上当前的月份，然后创建新的events集合用于写入。比如2016年的日志最终会被存储在如下12个集合里：

当需要清理历史数据时，直接将对应的集合删除掉：

不足之处，在于到时候，如果要查询多个月份的数据，查询的语句会稍微复杂些，需要从多个集合里查询结果来合并。

MongoDB应用1——日志分析

线上运行的服务会产生大量的运行及访问日志，日志里会包含一些错误、警告、及用户行为等信息。通常服务会以文本的形式记录日志信息，这样可读性强，方便于日常定位问题。但当产生大量的日志之后，要想从大量日志里挖掘出有价值的内容，则需要对数据进行进一步的存储和分析。

本文以存储 web 服务的访问日志为例，介绍如何使用 MongoDB 来存储、分析日志数据，让日志数据发挥最大的价值。本文的内容同样适用于其他的日志存储型应用。

一个典型的web服务器的访问日志类似如下，包含访问来源、用户、访问的资源地址、访问结果、用户使用的系统及浏览器类型等。

最简单存储这些日志的方法是，将每行日志存储在一个单独的文档里，每行日志在MongoDB里的存储模式如下所示：

上述模式虽然能解决日志存储的问题，但这些数据分析起来比较麻烦，因为文本分析并不是MongoDB所擅长的，更好的办法是把一行日志存储到MongoDB的文档里前，先提取出各个字段的值。如下所示，上述的日志被转换为一个包含很多个字段的文档。

同时，在这个过程中，如果您觉得有些字段对数据分析没有任何帮助，则可以直接过滤掉，以减少存储上的消耗。比如数据分析不会关心user信息、request、status信息，这几个字段没必要存储。ObjectId里本身包含了时间信息，没必要再单独存储一个time字段 (当然带上time也有好处，time更能代表请求产生的时间，而且查询语句写起来更方便，尽量选择存储空间占用小的数据类型）基于上述考虑，上述日志最终存储的内容可能类似如下所示：

日志存储服务需要能同时支持大量的日志写入，用户可以定制writeConcern来控制日志写入能力，比如如下定制方式：

同时，为了达到最优的写入效率，用户还可以考虑批量的写入方式，一次网络请求写入多条日志。格式如下所示：

db.events.insert([doc1, doc2, ...])

当日志按上述方式存储到MongoDB后，就可以按照各种查询需求查询日志了。

q_events = db.events.find({'path': '/apache_pb.gif'})

如果这种查询非常频繁，可以针对path字段建立索引，提高查询效率：

db.events.createIndex({path: 1})

通过对time字段建立索引，可加速这类查询：

db.events.createIndex({time: 1})

同样，用户还可以使用MongoDB的aggregation、maprece框架来做一些更复杂的查询分析，在使用时应该尽量建立合理的索引以提升查询效率。

当写日志的服务节点越来越多时，日志存储的服务需要保证可扩展的日志写入能力以及海量的日志存储能力，这时就需要使用MongoDB sharding来扩展，将日志数据分散存储到多个shard，关键的问题就是shard key的选择。

使用时间戳来进行分片（如ObjectId类型的_id，或者time字段），这种分片方式存在如下问题：

按照_id字段来进行hash分片，能将数据以及写入都均匀都分散到各个shard，写入能力会随shard数量线性增长。但该方案的问题是，数据分散毫无规律。所有的范围查询（数据分析经常需要用到）都需要在所有的shard上进行查找然后合并查询结果，影响查询效率。

假设上述场景里 path 字段的分布是比较均匀的，而且很多查询都是按path维度去划分的，那么可以考虑按照path字段对日志数据进行分片，好处是：

不足的地方是：

当然上述不足的地方也有办法改进，方法是给分片key里引入一个额外的因子,比如原来的shard key是 {path: 1}，引入额外的因子后变成：

{path: 1, ssk: 1} 其中ssk可以是一个随机值，比如_id的hash值，或是时间戳，这样相同的path还是根据时间排序的

这样做的效果是分片key的取值分布丰富，并且不会出现单个值特别多的情况。上述几种分片方式各有优劣，用户可以根据实际需求来选择方案。

分片的方案能提供海量的数据存储支持，但随着数据越来越多，存储的成本会不断的上升。通常很多日志数据有个特性，日志数据的价值随时间递减。比如1年前、甚至3个月前的历史数据完全没有分析价值，这部分可以不用存储，以降低存储成本，而在MongoDB里有很多方法支持这一需求。

MongoDB的TTL索引可以支持文档在一定时间之后自动过期删除。例如上述日志time字段代表了请求产生的时间，针对该字段建立一个TTL索引，则文档会在30小时后自动被删除。

db.events.createIndex( { time: 1 }, { expireAfterSeconds: 108000 } )

如果对日志保存的时间没有特别严格的要求，只是在总的存储空间上有*，则可以考虑使用capped collection来存储日志数据。指定一个最大的存储空间或文档数量，当达到阈值时，MongoDB会自动删除capped collection里最老的文档。

db.createCollection("event", {capped: true, size: 104857600000}

比如每到月底就将events集合进行重命名，名字里带上当前的月份，然后创建新的events集合用于写入。比如2016年的日志最终会被存储在如下12个集合里：

当需要清理历史数据时，直接将对应的集合删除掉：

不足之处，在于到时候，如果要查询多个月份的数据，查询的语句会稍微复杂些，需要从多个集合里查询结果来合并。

MongoDB如何优化查询性能？

站在用户的视角来看，如果一个搜索返回时间大于了1秒，就会让很多用户失去耐心。所以作为开发者而言，在开发过程中100%会遇到的一个问题就是优化数据的查询性能。那么在Mongo中是如何做查询性能优化呢？下面就给大家介绍一下。

在mongo中也提供了一个explain()方法，该方法能够提供大量与查询相关的信息。对于速度比较慢的查询来说，它是最重要的性能分析工具之一。通过查看一个查询的explain()输出信息，可以知道查询使用了哪个索引，以及是如何使用的。对于任意查询，都可以在最后添加一个explain()调用（与调用sort()或者limit()一样，不过explain()必须放在最后）。

      最常见的explain()输出有两种类型：使用索引的查询和没有使用索引的查询。其输出的信息可能如图1：

返回信息详细介绍：

“millis”表明了这个查询的执行时间。数字越小，则说明这个查询的效率越高。

“n”则表明了实际返回的文档数量。

“nscanned“描述了MongoDB在执行这个查询时搜索了多少文档。

”cursor“本查询返回值为”BasicCursor“则说明该查询未使用索引，所以才会搜索了所有的文档。如返回”BtreeCursor“则表示查询中使用了索引。

”isMultiKey“用于说明是否使用了多键索引。

”nYield“指本次查询暂停的次数。在查询期间，如果有与入请求需要处理，为了让写入请求能够顺利执行，查询会周期性的释放它的锁。

MongoDB 内存使用情况分析

MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。

MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bson 格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数 据库单表查询的绝大部分功能，而且还支持对数据建立索引。

先 ps 一下看看。

复制代码 代码如下:

$ ps aux|grep mongod

  mongo    26994  9.0 20.0 797264324 13243052 ?  Sl   May16 117:03 /path/to/mongodb/bin/mongod

总共 760G 多的虚拟内存，但是物理内存就只有 12.6G 。这个机器可是有 64G 内存的哦，这看起来 MongoDB 完全没用多少内存嘛。

再看看 free 的结果。

复制代码 代码如下:

$ free -m

total       used       free     shared    buffers     cached

  Mem:         64544      64279        265          0        134      60413

  -/+ buffers/cache:       3731      60813

  Swap:        31999          0      31999

内存倒是占得差不多了，基本都是 cached ，也就是文件系统缓存。MongoDB 是通过 mmap 方式让操作系统来处理持久化和缓存的。每个数据文件都直接映射到某个虚拟内存地址。访问的时候如果这一页不在内存中，系统就会尝试把这一页加载进来。这些 内存都是算进 cache 里的。在 mongodb 的官方文档里有这样一个说法，top 或 ps 里的 RSIZE 段显示的是机器的全部内存大小，因为 mongodb 会尽可能占用全部内存。但是事实上，这些缓存并没有算在里面。因此在 top 或 ps 中是看不出 MongoDB 的实际内存使用情况的。而 free 虽然可以看到系统的内存使用情况，但是没法确定这些内存里究竟有多少真的是 MongoDB 使用的。

还好有人做了 vmtouch 这个工具。可以检查文件在缓存中的情况，另外也可以把文件直接加载进缓存或者踢出去。只需要对 MongoDB 的所有数据文件检查一下缓存加载情况，就可以知道 MongoDB 到底缓存了多少数据了。

复制代码 代码如下:

$ vmtouch -m4G /path/to/mongodb/data/

      Files: 256

Directories: 3

    Resident Pages: 15465901/100219772  58G/382G  15.4%

    Elapsed: 4.072 seconds

这里 -m4G 是 vmtouch 检查的文件大小。MongoDB 的数据文件比较大，通常会超过默认的 500M。这样看来，缓存用了 58G，这还差不多。Resident Pages 左侧的数字是页的数量，页的数量乘以文件系统页大小才是内存使用量。页的大小可以通过

复制代码 代码如下:

getconf PAGESIZE

查看，通常是 4096，也就是 4KB。

MongoDB 在 NUMA 的机器上运行，并且内存被固定到一个 node 的时候，会有一个警告

复制代码 代码如下:

WARNING: You are running on a NUMA machine.

  We suggest launching mongod like this to avoid performance problems:

  numactl –interleave=all mongod [other options]

也许是认为，这种情况下只能用上一个节点的内存。但 MongoDB 的缓存是由操作系统管理的。NUMA 似乎对此并没有影响。而内存不太小的时候 MongoDB 本身很难用掉一个节点的内存。这种情况下，是否开启 numactl –interleave=all 作用已经不大了。能做的也许只能是加内存，sharding，或者换 ssd 了。