php网站开发和js,阿里巴巴logo设计理念,商品推广软文范例100字,ps网站首页怎么做哈喽大家好#xff0c;我是咸鱼。
今天分享一个在压测过程中遇到的问题#xff0c;当时排查这个问题费了我们好大的劲#xff0c;所以我觉得有必要写一篇文章来记录一下。
问题出现
周末在进行压测的时候#xff0c;测试和开发的同事反映压测有问题#xff0c;请求打到…哈喽大家好我是咸鱼。
今天分享一个在压测过程中遇到的问题当时排查这个问题费了我们好大的劲所以我觉得有必要写一篇文章来记录一下。
问题出现
周末在进行压测的时候测试和开发的同事反映压测有问题请求打到 A 服务上被拒绝了。
我们登录服务器查看 A 服务的日志发现频繁地报 Too many open files 错误可以看到压测的时候该进程要处理大量的 socket导致打开的文件描述符数量已经达到了操作系统允许的最大限制因此无法再打开更多的文件。
java.io.IOException: Too many open files...既然是系统资源相关的问题我们先 ulimit -n 看一下系统中进程能够使用的最大文件描述符是多少个
[rootlocalhost ~]# ulimit -n
100000为了稳妥起见我们还查看了 /etc/security/limits.conf 文件的内容
[rootlocalhost ~]# cat /etc/security/limits.conf
* soft nofile 100000
* hard nofile 100000可以看到系统限制进程能够最多打开 100000 个文件我们在服务器初始化的时候设置的值。但是压测的量还没上去A 服务上的进程打开文件数就超过了 10 万个吗
查看一下这个进程打开了多少个文件
[rootlocalhost ~]# cat /proc/该进程的 PID/fd | wc -l
8295我们发现该进程才打开了八千多个文件远远没有达到系统限制的 100000。
接着看下这个进程的文件描述符数量限制通过 /proc/Java 进程的 PID/limits 文件来查看
[rootlocalhost ~]# cat /proc/该进程的 PID/limits
...
Max open files 8192 8192 files
...奇怪按理说每个进程的文件描述符使用限制应该是 100000但是这里却显示只有 8192说明系统层面的资源限制在这个进程上没有生效而且这个 8192 是怎么来的为什么是 8192
我们重启了一下这个服务发现重启之后该进程的资源限制生效了Max open files 数量变成了 100000
# 重启服务
[rootlocalhost ~]# sh spring-boot.sh restart# 查看该进程的文件描述符数量限制
[rootlocalhost ~]# cat /proc/该进程的 PID/limits
...
Max open files 100000 100000 files
...定位问题
发现了这个现象之后我们接着排查了其他的服务发现服务进程的 Max open files 数量都是 8192而系统设置的却是 100000。
如果我们一旦手动重启服务进程的 Max open files 数就变成了系统设置的 100000。
我们在初始化服务器的时候已经修改了进程的最大打开文件数为 100000如果配置没有生效那也应该是系统的默认值 1024 而不是 8192。
就在一筹莫展的时候我们注意到了一个细微差别由于线上服务器较多平时我们都是通过 Saltstack 来管理服务包括服务的启动重启停止而今天是在终端上重启服务的所以会不会跟 Saltstack 相关
然后我们为了验证执行了下面的步骤
找到一台服务器先查看了上面进程的最大打开文件数发现是 8192。手动重启一下服务发现进程的最大打开文件数变成 100000我们在 salt-master 上远程重启这台服务发现进程的最大打开文件数变成了 8192。
接着我们在 salt-master 上远程执行 ulimit -a 命令
[rootsalt-master ~]# salt 服务器 ip cmd.run ulimit -a
...
open files (-n) 8192
...排查到这里终于有点柳暗花明的感觉了我们看一下这台服务器上 salt-minion 进程的资源限制
[rootlocalhost ~]# cat /proc/salt-minion 进程的 PID/limits
...
Max open files 8192 8192 files
...又因为 salt-minion 是通过 systemctl 来管理的所以我们在这台服务器上查看 salt-minion 的服务注册文件
[rootlocalhost ~]# cat /usr/lib/systemd/system/salt-minion.service
[Unit]
...[Service]
KillModeprocess
Typenotify
NotifyAccessall
LimitNOFILE8192
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。
LimitNOFILE8192当我们通过 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
[rootlocalhost ~]# vim /etc/systemd/system.conf
DefaultLimitNOFILE100000针对单个 service
这次案例的解决方法就是要修改单个 service 即 salt-minion的资源限制配置。
# 修改 salt-minion 的 service 文件改成和系统一样的资源限制配置
[rootlocalhost ~]# cat /usr/lib/systemd/system/salt-minion.service
...
[Service]
LimitNOFILE100000
...修改完之后别忘了重启。
[rootlocalhost ~]# systemctl daemon-reload[rootlocalhost ~]# systemctl restart salt-minion.service
