MongoDB启动报错Too many open files问题处理
题外话
本文是一次MongoDB生产环境启动故障处理记录，此环境虽为生产环境，但属于边缘业务，架构为MongoDB单机节点。
一、故障现象
故障具体情况
业务系统连接不上MongoDB数据库，重启不成功。（此MongoDB数据库版本为3.2.16，为单机节点，而且是通过supervisord管理）
检查发现如下错误日志：
二、故障处理
根据错误日志的输出，比较容易判断是文件句柄限制问题。
Linux是有文件句柄限制的，而且Linux默认一般都是1024。在生产环境中很容易到达这个值，因此这里就会成为系统的瓶颈，对于MongoDB来说，默认的文件打开数一般是不够的，需要使用ulimit去进行设置。
1、cat /etc/redhat-release
CentOS release 6.8 (Final)
2、修改当前交互终端的limit值
ulimit -n 655350.此时系统的文件句柄数为655350.
3、永久修改limit值
vim /etc/security/limits.conf
mongod soft nofile 655360
mongod hard nofile 655360
4、centos6还有的limit限制，/etc/security/limits.conf限制实际取决于/etc/security/limits.d/90-nproc.conf的配置，也就是说哪怕/etc/security/limits.conf设置最大打开数是65535，而/etc/security/limits.d/20-nproc.conf里配的是4096，那最终结果还是用户最大只能打开4096个文件句柄,所以还要再修改20-nproc.conf
（如果是centos7，则是/etc/security/limits.d/90-nproc.conf）
vim /etc/security/limits.d/90-nproc.conf
* soft nproc 655360
root soft nproc unlimited
5、OS其他地方可能影响文件最大打开句柄都做设置
vim /proc/sys/fs/file-max
655360
vim /etc/rc.d/rc.local
fs.file-max=655360
vim /etc/sysctl.conf
fs.file-max=655360
以上设置完成后，需重启服务器生效。
三、故障再次分析处理
服务器重启后，再次用启动MongoDB（用supervisord启动），发现还是不能成功启动，错误日志也是一样的报错输出Too many open files。（有点纳闷，该设置的地方都设置了）
纳闷之后，采用了手动启MongoDB的方法，等待几分钟后，MongoDB正常启动了,说明OS的limit限制是设置正常了，猜想大概率是supervisord的问题。为了数据安全，先把好不容易启动的MongoDB备份，数据量10多G，贴上备份语句：
./mongodump -h 127.0.0.1:21001 -d log -o /data/mongo_dump/db.log.20200722
数据库备份好就安心多了，虽然猜想大概率是进程管理工具supervisor的问题，但一时没找到具体原因。然后进入MongoDB库里面，发现有个log数据库下面collection非常多（竟然一天一个日志文件，而且每个日志文件一个collection），为了优先恢复生产环境，和业务沟通后，表示可以删除一部分以前的历史log文件。
PS：因为前面已经备份了，所以可能根据实际情况做删除操作．
批量删除2018年的log
echo 'show collections'|./mongo 127.0.0.1:21001/log | grep "#2018" | xargs -n 1 printf "printjson(db.getCollection('%s').drop());\n" > /data/mongo_del.js
./mongo 127.0.0.1:21001/log /data/mongo_del.js
删掉部分log以后，用supervisord重启MongoDB服务，终于成功启动，生产环境问题得到解决。
PS：生产环境问题解决后，在测试环境还原场景，多次测试终于找出罪魁祸首，进程管理工具supervisor自身的一个配置限制，需修改/etc/rc5.d/S90supervisord这个文件里面的ulimit值。
哎哟，不错噢！ - - - - - - 欢迎指出有误的地方以及补充更好的方法