MongoDB——关于内存使用 (转)

MongoDB 内存用在哪？

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

存储引擎 Cache

MongoDB 3.2 及以后，默认使用 WiredTiger 存储引擎，可通过 cacheSizeGB选项配置 WiredTiger 引擎使用内存的上限，一般建议配置在系统可用内存的60%左右（默认配置）。

举个例子，如果 cacheSizeGB 配置为 10GB，可以认为 WiredTiger 引擎通过tcmalloc分配的内存总量不会超过10GB。为了控制内存的使用，WiredTiger 在内存使用接近一定阈值就会开始做淘汰，避免内存使用满了阻塞用户请求。

目前有4个可配置的参数来支持 wiredtiger 存储引擎的 eviction 策略（一般不需要修改），其含义是：

 

 

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

 

 

 

如何控制内存使用？

合理配置 WiredTiger cacheSizeGB

• 如果一个机器上只部署 Mongod，mongod 可以使用所有可用内存，则是用默认配置即可。
• 如果机器上多个mongod混部，或者mongod跟其他的一些进程一起部署，则需要根据分给mongod的内存配额来配置 cacheSizeGB，按配额的60%左右配置即可。

控制并发连接数

TCP连接对 mongod 的内存开销上面已经详细分析了，很多同学对并发有一定误解，认为「并发连接数越高，数据库的QPS就越高」，实际上在大部分数据库的网络模型里，连接数过高都会使得后端内存压力变大、上下文切换开销变大，从而导致性能下降。

MongoDB driver 在连接 mongod 时，会维护一个连接池（通常默认100），当有大量的客户端同时访问同一个mongod时，就需要考虑减小每个客户端连接池的大小。mongod 可以通过配置 net.maxIncomingConnections 配置项来限制最大的并发连接数量，防止数据库压力过载。

是否应该配置 SWAP

官方文档上的建议如下，意思是配置一下swap，避免mongod因为内存使用太多而OOM。

For the WiredTiger storage engine, given sufficient memory pressure, WiredTiger may store data in swap space.

Assign swap space for your systems. Allocating swap space can avoid issues with memory contention and can prevent 
the OOM Killer on Linux systems from killing mongod.

开启 SWAP 与否各有优劣，SWAP开启，在内存压力大的时候，会利用SWAP磁盘空间来缓解内存压力，此时整个数据库服务会变慢，但具体变慢到什么程度是不可控的。不开启SWAP，当整体内存超过机器内存上线时就会触发OOM killer把进程干掉，实际上是在告诉你，可能需要扩展一下内存资源或是优化对数据库的访问了。

是否开启SWAP，实际上是在「好死」与「赖活着」的选择，个人觉得，对于一些重要的业务场景来说，首先应该为数据库规划足够的内存，当内存不足时，「及时调整扩容」比「不可控的慢」更好。

其他

• 尽量减少内存排序的场景，内存排序一般需要更多的临时内存
• 主备节点配置差距不要过大，备节点会维护一个buffer（默认最大256MB）用于存储拉取到oplog，后台从buffer里取oplog不断重放，当备同步慢的时候，这个buffer会持续使用最大内存。
• 控制集合及索引的数量，减少databse管理元数据的内存开销；集合、索引太多，元数据内存开销是一方面的影响，更多的会影响启动加载的效率、以及运行时的性能。

 

 

 

 

 

通过修改MongoDB的配置文件限制其可以使用的内存

MongoDB的内存限制参数配置：
3.X: /etc/mongod.conf
4.X: /etc/mongod.conf.orig

常用基本配置文件参数

storage:
  # mongod 进程存储数据目录，此配置仅对 mongod 进程有效
  dbPath: /data/mongodb/db
  是否开启 journal 日志持久存储，journal 日志用来数据恢复，是 mongod 最基础的特性，通常用于故障恢复。64 位系统默认为 true，32 位默认为 false，建议开启，仅对 mongod 进程有效。
  journal:
    enabled: true
 # 存储引擎类型，mongodb 3.0 之后支持 “mmapv1”、“wiredTiger” 两种引擎，默认值为“mmapv1”；官方宣称 wiredTiger 引擎更加优秀。
  engine: mmapv1

systemLog:
  # 日志输出目的地，可以指定为 “file” 或者“syslog”，表述输出到日志文件，如果不指定，则会输出到标准输出中（standard output）
  destination: file
  # 如果为 true，当 mongod/mongos 重启后，将在现有日志的尾部继续添加日志。否则，将会备份当前日志文件，然后创建一个新的日志文件；默认为 false。
  logAppend: true
  # 日志路径
  path: /var/log/mongodb/mongod.log

net:
 # 指定端口
  port: 27017
  # 绑定外网 op 多个用逗号分隔
  bindIp: 0.0.0.0
  maxIncomingConnections: 10000

内存优化相关的配置

MongoDB 在使用过程中， 内存占用会越来越大， 甚至达到危险的状态， 而且会一直保持最高状态， 官网上有相关的内容：https://docs.mongodb.com/v3.4/core/wiredtiger/index.html 以下根据官网， 增加限制内存的配置， 启动mongo使用配置文件启动

storage:
  dbPath: /data/mongodb/db
  journal:
    enabled: true
  engine: wiredTiger
    # 如下配置仅对 wiredTiger 引擎生效（3.0 以上版本）  
  	wiredTiger:
  	  # wiredTiger 缓存工作集（working set）数据的内存大小，单位：GB
      # 此值决定了 wiredTiger 与 mmapv1 的内存模型不同，它可以限制 mongod 对内存的使用量，而 mmapv1 则不能（依赖于系统级的 mmap）。
默认情况下，cacheSizeGB 的值为假定当前节点只部署一个 mongod 实例，此值的大小为物理内存的一半；
如果当前节点部署了多个 mongod 进程，那么需要合理配置此值。如果 mongod 部署在虚拟容器中（比如，lxc，cgroups，Docker）等，
它将不能使用整个系统的物理内存，则需要适当调整此值。默认值为物理内存的一半。
      engineConfig:
      	cacheSizeGB: 5

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log
  
net:
  port: 27017
  bindIp: 0.0.0.0
  maxIncomingConnections: 10000