运维排查 | Saltstack 最大打开文件数问题之奇怪的 8192

文章摘要

本文描述了作者在压测过程中遇到的 "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值，并重启相关服务使配置生效。

想要了解更多内容？

查看原文：运维排查 | Saltstack 最大打开文件数问题之奇怪的 8192

文章来源：

咸鱼运维杂谈

扫码关注公众号