Saltstack 最大打开文件数问题之奇怪的 8192

2024-03-22 19:52

本文主要是介绍Saltstack 最大打开文件数问题之奇怪的 8192,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

哈喽大家好,我是咸鱼。

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

问题出现

周末在进行压测的时候,测试和开发的同事反映压测有问题,请求打到 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.conflimits.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 

这篇关于Saltstack 最大打开文件数问题之奇怪的 8192的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/836082

相关文章

SpringBoot启动报错的11个高频问题排查与解决终极指南

《SpringBoot启动报错的11个高频问题排查与解决终极指南》这篇文章主要为大家详细介绍了SpringBoot启动报错的11个高频问题的排查与解决,文中的示例代码讲解详细,感兴趣的小伙伴可以了解一... 目录1. 依赖冲突:NoSuchMethodError 的终极解法2. Bean注入失败:No qu

MySQL新增字段后Java实体未更新的潜在问题与解决方案

《MySQL新增字段后Java实体未更新的潜在问题与解决方案》在Java+MySQL的开发中,我们通常使用ORM框架来映射数据库表与Java对象,但有时候,数据库表结构变更(如新增字段)后,开发人员可... 目录引言1. 问题背景:数据库与 Java 实体不同步1.1 常见场景1.2 示例代码2. 不同操作

如何解决mysql出现Incorrect string value for column ‘表项‘ at row 1错误问题

《如何解决mysql出现Incorrectstringvalueforcolumn‘表项‘atrow1错误问题》:本文主要介绍如何解决mysql出现Incorrectstringv... 目录mysql出现Incorrect string value for column ‘表项‘ at row 1错误报错

如何解决Spring MVC中响应乱码问题

《如何解决SpringMVC中响应乱码问题》:本文主要介绍如何解决SpringMVC中响应乱码问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Spring MVC最新响应中乱码解决方式以前的解决办法这是比较通用的一种方法总结Spring MVC最新响应中乱码解

pip无法安装osgeo失败的问题解决

《pip无法安装osgeo失败的问题解决》本文主要介绍了pip无法安装osgeo失败的问题解决,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一... 进入官方提供的扩展包下载网站寻找版本适配的whl文件注意:要选择cp(python版本)和你py

解决Java中基于GeoTools的Shapefile读取乱码的问题

《解决Java中基于GeoTools的Shapefile读取乱码的问题》本文主要讨论了在使用Java编程语言进行地理信息数据解析时遇到的Shapefile属性信息乱码问题,以及根据不同的编码设置进行属... 目录前言1、Shapefile属性字段编码的情况:一、Shp文件常见的字符集编码1、System编码

Spring MVC使用视图解析的问题解读

《SpringMVC使用视图解析的问题解读》:本文主要介绍SpringMVC使用视图解析的问题解读,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Spring MVC使用视图解析1. 会使用视图解析的情况2. 不会使用视图解析的情况总结Spring MVC使用视图

Redis解决缓存击穿问题的两种方法

《Redis解决缓存击穿问题的两种方法》缓存击穿问题也叫热点Key问题,就是⼀个被高并发访问并且缓存重建业务较复杂的key突然失效了,无数的请求访问会在瞬间给数据库带来巨大的冲击,本文给大家介绍了Re... 目录引言解决办法互斥锁(强一致,性能差)逻辑过期(高可用,性能优)设计逻辑过期时间引言缓存击穿:给

Java程序运行时出现乱码问题的排查与解决方法

《Java程序运行时出现乱码问题的排查与解决方法》本文主要介绍了Java程序运行时出现乱码问题的排查与解决方法,包括检查Java源文件编码、检查编译时的编码设置、检查运行时的编码设置、检查命令提示符的... 目录一、检查 Java 源文件编码二、检查编译时的编码设置三、检查运行时的编码设置四、检查命令提示符

Jackson库进行JSON 序列化时遇到了无限递归(Infinite Recursion)的问题及解决方案

《Jackson库进行JSON序列化时遇到了无限递归(InfiniteRecursion)的问题及解决方案》使用Jackson库进行JSON序列化时遇到了无限递归(InfiniteRecursi... 目录解决方案‌1. 使用 @jsonIgnore 忽略一个方向的引用2. 使用 @JsonManagedR