Wizzer.cn

Mongod 的服务模型是每个网络连接由一个单独的线程来处理，每个线程配置了1MB 的栈空间，当网络连接数太多时，过多的线程会导致上下文切换开销变大，同时内存开销也会上涨。

• 连接是要消耗资源的，而且消耗的并不少。
  • 内存：MongoDB为例，每个线程都要分配1MB的栈内存出来。1000个连接，1G内存就这么没了，甭管是否是活跃连接
  • 文件句柄：每个连接都要打开一个文件句柄，当然从成本上讲，这个消耗相对内存是小了很多。但换个角度，文件句柄也被其他模块消耗着，比如WT存储引擎，就需要消耗大量的文件句柄
• 是否真的需要这么多的链接，一般的业务场景下请求压力在1000QPS左右，按照每个请求50ms计算，最多也就需要1000/(1000/50)==50个链接即可满足需求，并且是整个系统50个链接即可。
• 很多人平时没有怎么注意过链接数概念，上云后发现居然有这样的限制，心里很不舒服，可能非常不理解。这里说下常见的两种情况：
  • 短链接：一般都是PHP环境，因为PHP的框架决定了PHP短链接的特性，并且链接数的需求一般是在1000-3000左右，具体多少还要根据业务部署的PHP数量来计算。并且MongoDB开源版本在短链接Auth处理上并不优雅，会消耗非常多的CPU资源，3000链接即可跑满24Core的CPU。PHP大拿Facebook也有同样的问题，所以他们用go语言自行开发了一套Proxy代理，来解决对MongoDB的短链接请求问题，但这毕竟带来部署成本和兼容性问题。
  • 长链接：比较健康合理的使用方式，但是也要正确的配置客户端，相关的参数为&maxPoolSize=xx 在ConnectionURI上追加上去即可，否则默认每个客户端就是高处100来个，平白的浪费资源
• 链接数的上限需要综合考虑性能，稳定性，业务需求。多方面去考虑，缺一不可。超低的内存，配置超高的链接数，得到的只能是OOM。