关于mongodb3.4的内存的一些困惑

Question

大家好，有个问题想请大家帮忙解惑。
我们前段时间将mongodb升级到3.4.6，我们每天有个删除历史数据的动作，数据库只保存几天的数据，数据量不大
scm:PRIMARY> show dbs
admin 0.000GB
local 15.234GB
scm 4.198GB
scm:PRIMARY>
包括local里面的oplog一共才20G
但是通过top和mongodb自己的命令查看内存情况，发现远远超过了20G
通过db.serverStatus().wiredTiger.cache查看

    "bytes belonging to page images in the cache" : 27709364089,
    **"bytes currently in the cache" : 85890560448,--大约80G**
    "bytes not belonging to page images in the cache" : 58181196359,
    "bytes read into cache" : 51861301488,
    "bytes written from cache" : NumberLong("4133625131732"),
    **"maximum bytes configured" : 107374182400,--设置最大inner内存wiredTigerCacheSizeGB=100**
    "maximum page size at eviction" : 4481266,

通过db.serverStatus().mem查看

    **"resident" : 106492,--大约106G 应该是file system cache=106-80=24G**
    "virtual" : 112000,

问题1:：80G的inner cache包含哪些数据，我知道的有热数据和索引（现在看来，即使是所有的数据放到内存，包含oplog，也才20G），还有oplog会占内存吗。
问题2：inner cache可以通过wiredTigerCacheSizeGB参数设置最大大小，那么file system cache大小有什么办法限制吗，现在看来这个file system cache很大，里面主要存了什么数据

Answer 1

1. oplog 在 MongoDB 里是一个普通的 capped collection，对于存储引擎来说，oplog只是一部分普通的数据而已。所以，在开启复制集的时候，oplog应该会在内存里，因为oplog会经常性地被重放来达到数据同步的作用。
2. 第二个问题搭车期待大牛回答。

Answer 2

你需要复习一下操作系统原理。file system cache并不是任何一个应用来控制的，而是由操作系统控制。操作系统用没有被使用的内存缓冲一些读过的文件内容。因为反正也没人用，放在那里空着就浪费了。如果缓冲一些内容，就会有一定的机会被重复利用，总比空着好。如果有其他应用需要使用这部分内存，操作系统会释放掉。所以你不用太关心file system cache的问题。