MongoDB 如何使用内存？为什么内存满了？

Mongod 进程启动后，除了跟普通进程一样，加载 binary、依赖的各种library 到内存，其作为一个DBMS，还需要负责客户端连接管理，请求处理，数据库元数据、存储引擎等很多工作，这些工作都涉及内存的分配与释放，默认情况下，MongoDB 使用 Google tcmalloc 作为内存分配器，内存占用的大头主要是「存储引擎」与 「客户端连接及请求的处理」。

在这个规则下，一个正常运行的 MongoDB 实例，cache used 一般会在 0.8 * cacheSizeGB 及以下，偶尔超出问题不大；如果出现 used>=95% 或者 dirty>=20%，并一直持续，说明内存淘汰压力很大，用户的请求线程会阻塞参与page淘汰，请求延时就会增加，这时可以考虑「扩大内存」或者 「换更快的磁盘提升IO能力」。

redhat7(redhat6上并没有导出这么详细的信息） 上通过 ss -m 可以查看每个连接的buffer的信息，如下是一个示例，读写 buffer 分别占了 2357478bytes、2626560bytes，即均在2MB左右；500个类似的连接就会占用掉 1GB 的内存；buffer 占到多大，取决于连接上发送/应答的数据包的大小、网络质量等，如果请求应答包都很小，这个buffer也不会涨到很大；如果包比较大，这个buffer就更容易涨的很大。

除了协议栈上的内存开销，针对每个连接，Mongod 会起一个单独的线程，专门负责处理这条连接上的请求，mongod 为处理连接请求的线程配置了大1MB的线程栈，通常实际使用在几十KB左右，通过 proc 文件系统看到这些线程栈的实际开销。 除了处理请求的线程，mongod 还有一系列的后台线程，比如主备同步、定期刷新 Journal、TTL、evict 等线程，默认每个线程大ulimit -s（一般10MB）的线程栈，由于这批线程数量比较固定，占的内存也比较可控。

线程在处理请求时，需要分配临时buffer存储接受到的数据包，为请求建立上下文（OperationContext），存储中间的处理结果（如排序、aggration等）以及终的应答结果等。

当有大量请求并发时，可能会观察到 mongod 使用内存上涨，等请求降下来后又慢慢释放的行为，这个主要是 tcmalloc 内存管理策略导致的，tcmalloc 为性能考虑，每个线程会有自己的 local free page cache，还有 central free page cache；内存申请时，按 local thread free page cache ==> central free page cache 查找可用内存，找不到可用内存时才会从堆上申请；当释放内存时，也会归还到 cache 里，tcmalloc 后台慢慢再归还给 OS， 默认情况下，tcmalloc 多会 cache min（1GB，1/8 * system_memory） 的内存， 通过 setParameter.tcmallocMaxTotalThreadCacheBytesParameter 参数可以配置这个值，不过一般不建议修改，尽量在访问层面做调优）

tcmalloc cache的管理策略，MongoDB 层暴露了几个参数来调整，一般不需要调整，如果能清楚的理解tcmalloc原理及参数含义，可做针对性的调优；MongoDB tcmalloc 的内存状态可以通过 db.serverStatus().tcmalloc 查看，具体含义可以看 tcmalloc 的文档。重点可以关注下 total_free_bytes，这个值告诉你有多少内存是 tcmalloc 自己缓存着，没有归还给 OS 的。