运维排查 | Saltstack 最大打开文件数问题之奇怪的 8192
![](/theme/default/default/images/main/eye-open.png)
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
![](/theme/default/default/images/main/icon-jing.png)
文章摘要
本文描述了作者在压测过程中遇到的 "Too many open files" 错误问题及其解决过程。在压测期间,服务A无法处理更多请求,因为进程打开的文件描述符数量已经达到操作系统的最大限制。通过查看系统配置和进程的文件描述符限制,发现尽管系统允许每个进程打开的文件数量为100000,但实际上服务A的进程限制只有8192。重启服务后,这个限制被正确更新为100000。
定位问题
排查发现,所有服务的进程 "Max open files" 数量默认为8192,而非系统设置的100000。手动重启服务后,进程的文件描述符数量限制会更新为系统设置值。进一步排查发现,使用Saltstack管理的服务不会应用系统的文件描述符限制,而这是由于Saltstack管理的服务是通过salt-minion进程启动的,该进程的文件描述符限制被设置为8192。
资源限制的工作机制
系统的 /etc/security/limits.conf 文件配置对通过PAM认证登录的用户有效,但在使用Systemd作为init系统的操作系统中,如CentOS 7/RHEL 7,Systemd会忽略limits.conf中的设置,使用自己的资源管理机制。因此,自动启动的服务可能不会应用limits.conf的限制。
解决问题
了解到Systemd不会使用limits.conf中的配置后,解决方法包括全局配置systemd服务的资源限制或针对单个服务进行配置。全局配置可以在 /etc/systemd/system.conf 文件中设置DefaultLimitNOFILE值。针对单个服务,如salt-minion,需要修改其systemd服务文件中的LimitNOFILE值,并重启相关服务使配置生效。
想要了解更多内容?
![](/theme/default/default/images/main/icon-jing.png)
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)