MongoDB线程创建失败报错，TaskMax配置是否为诱因？

我之前帮不少用户排查过这类MongoDB线程创建失败的问题，你的日志里的报错：

2018-02-08T15:05:25.267-0600 I - [thread2] pthread_create failed: Resource temporarily unavailable
2018-02-08T15:05:25.267-0600 I - [thread2] failed to create service entry worker thread for 10.20.9.217:18465
2018-02-08T15:05:25.272-0600 F - [conn27232] std::exception::what(): Resource temporarily unavailable Actual exception type: std::system_error

答案是肯定的：TaskMax配置完全可能导致这个问题。

为什么TaskMax会引发这个错误？ #

systemd的TaskMax参数用于限制单个服务进程及其子进程能创建的任务总数（这里的任务包括线程和进程）。MongoDB在运行过程中，会为每个客户端连接创建对应的线程，同时还有后台的worker线程（比如你日志里提到的service entry worker线程）来处理后台任务。当mongod进程的线程数达到TaskMax设定的上限时，系统就会拒绝创建新线程，直接触发pthread_create failed的资源不可用错误。

如何验证是不是TaskMax的问题？ #

1. 查看当前mongod.service的TaskMax配置：

   systemctl show mongod.service --property TaskMax
   

2. 查看当前mongod进程的实际线程数：

   ps -o nlwp $(pidof mongod)
   

如果实际线程数接近或超过TaskMax的数值，那基本可以确定就是这个配置导致的问题。

解决办法 #

修改你的mongod.service配置文件，调整TaskMax的数值（可以设置为一个足够大的数，或者直接设为无限制）：

[Service]
# 可以设置为具体数值，比如10000，或者用infinity表示无限制
TaskMax=10000

修改后重新加载systemd配置并重启服务：

systemctl daemon-reload
systemctl restart mongod.service

其他可能的排查方向 #

当然，除了TaskMax，系统级别的线程限制（比如通过ulimit -u查看的用户最大进程数）也可能导致类似错误，但根据你的提问重点，TaskMax是最需要优先排查的因素。

内容的提问来源于stack exchange，提问作者Esteban Kolmaier