哈喽大家好，我是咸鱼。

今天分享一个在压测过程中遇到的问题，当时排查这个问题费了我们好大的劲，所以我觉得有必要写一篇文章来记录一下。

问题出现

周末在进行压测的时候，测试和开发的同事反映压测有问题，请求打到 A 服务上被拒绝了。

我们登录服务器查看 A 服务的日志，发现频繁地报 Too many open files 错误，可以看到压测的时候该进程要处理大量的 socket，导致打开的文件描述符数量已经达到了操作系统允许的最大限制，因此无法再打开更多的文件。

java.io.IOException: Too many open files
	...

既然是系统资源相关的问题，我们先 ulimit -n 看一下系统中进程能够使用的最大文件描述符是多少个：

[root@localhost ~]# ulimit -n 
100000

为了稳妥起见，我们还查看了 /etc/security/limits.conf 文件的内容：

[root@localhost ~]# cat /etc/security/limits.conf
*           soft    nofile          100000
*           hard    nofile          100000

可以看到系统限制进程能够最多打开 100000 个文件（我们在服务器初始化的时候设置的值）。但是压测的量还没上去，A 服务上的进程打开文件数就超过了 10 万个吗？

查看一下这个进程打开了多少个文件：

[root@localhost ~]# cat /proc/<该进程的 PID>/fd | wc -l
8295

我们发现该进程才打开了八千多个文件，远远没有达到系统限制的 100000。

接着看下这个进程的文件描述符数量限制，通过 /proc/<Java 进程的 PID>/limits 文件来查看

[root@localhost ~]# cat /proc/<该进程的 PID>/limits
...
Max open files            8192               8192               files
...

奇怪，按理说每个进程的文件描述符使用限制应该是 100000，但是这里却显示只有 8192，说明系统层面的资源限制在这个进程上没有生效，而且这个 8192 是怎么来的，为什么是 8192 ？

我们重启了一下这个服务，发现重启之后该进程的资源限制生效了，Max open files 数量变成了 100000 ！

# 重启服务
[root@localhost ~]# sh spring-boot.sh restart

# 查看该进程的文件描述符数量限制
[root@localhost ~]# cat /proc/<该进程的 PID>/limits
...
Max open files            100000               100000               files
...

定位问题

发现了这个现象之后，我们接着排查了其他的服务，发现服务进程的 Max open files 数量都是 8192，而系统设置的却是 100000。

如果我们一旦手动重启服务，进程的 Max open files 数就变成了系统设置的 100000。

我们在初始化服务器的时候，已经修改了进程的最大打开文件数为 100000，如果配置没有生效，那也应该是系统的默认值 1024 ，而不是 8192。

就在一筹莫展的时候，我们注意到了一个细微差别：由于线上服务器较多，平时我们都是通过 Saltstack 来管理服务（包括服务的启动重启停止），而今天是在终端上重启服务的，所以会不会跟 Saltstack 相关？

然后我们为了验证执行了下面的步骤：

1. 找到一台服务器，先查看了上面进程的最大打开文件数，发现是 8192。
2. 手动重启一下服务，发现进程的最大打开文件数变成 100000
3. 我们在 salt-master 上远程重启这台服务，发现进程的最大打开文件数变成了 8192。

接着我们在 salt-master 上远程执行 ulimit -a 命令

[root@salt-master ~]# salt <服务器 ip> cmd.run 'ulimit -a'
...
open files                      (-n) 8192
...

排查到这里，终于有点柳暗花明的感觉了，我们看一下这台服务器上 salt-minion 进程的资源限制：

[root@localhost ~]# cat /proc/<salt-minion 进程的 PID>/limits
...
Max open files            8192                 8192                 files 
...

又因为 salt-minion 是通过 systemctl 来管理的，所以我们在这台服务器上查看 salt-minion 的服务注册文件：

[root@localhost ~]# cat /usr/lib/systemd/system/salt-minion.service 
[Unit]
...

[Service]
KillMode=process
Type=notify
NotifyAccess=all
LimitNOFILE=8192
ExecStart=/usr/bin/salt-minion

[Install]
...

果然，奇怪的 8192 出现在了这两处地方！

关于 Linux 下 Ulimit 资源限制

首先，/etc/security/limits.conf 文件中的配置对于通过 PAM 认证登录的用户资源限制是有效的。

也就是说，登陆了系统的用户，无论是交互式登录还是非交互式登录，其资源限制都会受到 limits.conf 中的配置影响。

但是，在 CentOS 7/RHEL 7 等系统中，默认采用 Systemd 作为 init 系统，取代了之前的 SysV init，对于 Systemd 启动的服务（例如使用 systemctl 启动的服务），limits.conf 中的配置对其资源限制是不生效的。

这是因为 Systemd 会忽略 limits.conf 中的设置，而是使用自己的资源管理机制。

这里补充一下，在 CenOS 5/6 中，/etc/security/limits.conf 和 /etc/security/limits.d 中的配置文件是为通过PAM登录的用户设置资源限制的。这些限制在用户登录时由PAM模块加载并应用（什么是 PAM ，你可以简单理解为一般情况登陆了终端都会加载 PAM 模块），因此仅在用户会话期间生效。

所以就会出现某进程在机器重启后资源限制设置与 /etc/security/limits.conf 和 limits.d 下的文件不一致的问题，可能是因为进程是在系统启动时自动启动的，而不是通过用户登录而启动的。因此不会受到 PAM 模块加载的影响。在这种情况下，进程的资源限制可能受到系统级别的默认限制或其他配置文件的影响。

我们对某一台 CentOS 6 的机器进行重启后，发现上面设置了开机自启动的进程的资源限制都发生了变化（变成了系统设置的默认值），一旦我们手动重启，资源限制则设置成了跟 /etc/security/limits.conf 文件设置的一致

对于一些设置了开机自启动的进程，如果在机器重启后保持资源限制不发生变化，可以在进程的启动脚本里加上关于资源限制设置的命令，比如说 ulimit -SHn 10000

所以在 Systemd 中，可以通过在服务单元文件中设置 Limit* 选项来控制服务的资源限制，比如限制进程的最大打开文件数 LimitNOFILE 为 8192。

LimitNOFILE=8192

当我们通过 Salt-master 来管理远程服务器的时候（服务器上面往往部署了 Salt-minion），即 Salt-master 发送命令给 Salt-minion 时，通常情况下，Salt-minion 会直接在自身进程中执行相应的操作。

如果是通过 Salt-minion 来启动一个进程，这个进程则会继承 Salt-minion 的资源限制配置。

这也就是为什么通过 salt-minion 管理的进程的最大打开文件数都是 8192，因为 salt-minion 的最大打开文件数就是 8192。

解决问题

既然知道了这是关于 systemd services 的资源限制相关的问题，那就好解决了。

• 针对所有的 service ：

配置 systemd services 的资源限制可以在全局范围内进行。这些配置文件分别位于 /etc/systemd/system.conf 和 /etc/systemd/user.conf。

system.conf 文件适用于系统级实例，而 user.conf 文件适用于用户级实例。一般建议在 system.conf 中配置服务的资源限制，但如果在 /etc/systemd/system.conf 文件中修改配置，则需要重启系统才能使更改生效。

此外，还可以通过在 /etc/systemd/system.conf.d/ 和 /etc/systemd/user.conf.d/ 目录中放置 .conf 文件进行配置。

需要注意的是，system.conf.d/*.conf 中的配置会覆盖 system.conf 中的配置。

如果你打算修改所有通过 systemctl 管理的服务进程的资源限制（比如修改最大文件打开数量）

那可以修改/etc/systemd/system.conf

[root@localhost ~]# vim /etc/systemd/system.conf
DefaultLimitNOFILE=100000

• 针对单个 service：

这次案例的解决方法就是要修改单个 service （即 salt-minion）的资源限制配置。

# 修改 salt-minion 的 service 文件，改成和系统一样的资源限制配置
[root@localhost ~]# cat /usr/lib/systemd/system/salt-minion.service 
...
[Service]
LimitNOFILE=100000
...

修改完之后别忘了重启。

[root@localhost ~]# systemctl daemon-reload

[root@localhost ~]# systemctl restart salt-minion.service