关于 ulimit 的两个天坑

稍微有点 Linux 经验的人一定会遇到过 “Too many open files” 错误,这个错误本质是 ulimit 设置不合理导致的。关于 ulimit 设置,有哪些需要注意的点呢?本文给大家做一个介绍,希望对大家有所帮助。

如何确认 ulimit 设置生效了?

很多人设置了 ulimit 最后发现还是报错 “Too many open files”。先不论如何操作,我们先要知道怎么确认进程的 ulimit 到底是多少。这不是通过 ulimit -n 来看的,而是找到进程的 pid,然后查看 /proc/<进程的PID>/limits 文件,这个文件里面记录了进程的真实 ulimit 信息。比如:

20240401155313

如何设置 ulimit?

如果 ssh 到机器上,通过 nohup 之类的方式启动进程,ulimit 将受限于 /etc/security/limits.conf 文件的配置。比如我这个机器:

[root@aliyun-2c2g40g3m ~]# cat /etc/security/limits.conf | grep -v '^#' | grep -v '^$'
root soft nofile 65535
root hard nofile 65535
* soft nofile 65535
* hard nofile 65535

这是 aliyun 的一台虚机,看起来阿里云已经帮我们设置了 ulimit 为 65535,这个是 OK 的,挺大的了。但是,如果你是通过 systemd 启动的服务,ulimit 将受限于 systemd 的配置。比如某个服务的 service 文件设置为:

[Unit]
Description="Categraf"
After=network.target

[Service]
Type=simple

ExecStart=/opt/categraf/categraf
WorkingDirectory=/opt/categraf

Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65535
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=categraf


[Install]
WantedBy=multi-user.target

看到 LimitNOFILE 那行配置了么?就是它。

如果 service 文件中没有配置 LimitNOFILE,systemd 会有个默认配置,systemd 的默认配置可以通过如下方式查看:

[root@aliyun-2c2g40g3m systemd]# pwd
/etc/systemd
[root@aliyun-2c2g40g3m systemd]# grep FILE *.conf
system.conf:#DefaultLimitNOFILE=
user.conf:#DefaultLimitNOFILE=

咱也不用关心默认配置是多少,反正每个 service 都配置一下 LimitNOFILE 就好了。

其他进程管理工具对 ulimit 也有影响

如果你不是通过 systemd 托管进程的,而是使用了其他的进程管理工具,比如 supervisor,那么 ulimit 将受限于 supervisor 的配置。如果你是通过 Saltstack 之类的工具,批量通过 shell 启动进程,还要小心 salt minion 的 ulimit 设置,至于 supervisor 和 salt minion 如何调整 ulimit,这里就不展开了,说多了都是泪。

句柄限制不止是 ulimit

实际上,操作系统对句柄的限制不止是 ulimit,还有 /proc/sys/fs/file-max 这个参数,这个参数限制了整个系统的句柄数量。如果你的系统句柄数量设置过小,那么即使你设置了 ulimit,也会受限于这个参数。比如我的系统如下:

[root@aliyun-2c2g40g3m systemd]# cat /proc/sys/fs/file-max
188844

如何调整这个参数呢?操作命令如下:

[root@aliyun-2c2g40g3m systemd]# echo 100000 > /proc/sys/fs/file-max
[root@aliyun-2c2g40g3m systemd]# cat /proc/sys/fs/file-max
100000
[root@aliyun-2c2g40g3m systemd]# echo 188844 > /proc/sys/fs/file-max
[root@aliyun-2c2g40g3m systemd]# cat /proc/sys/fs/file-max
188844

如果想要机器重启也能生效,就要修改 sysctl.conf 文件,比如:

fs.file-max = 188844

如何监控句柄相关问题?

系统层面总共分配了多少句柄可以通过 /proc/sys/fs/file-nr 文件查看,比如:

[root@aliyun-2c2g40g3m systemd]# cat /proc/sys/fs/file-nr
1760	0	188844

第一个数字是已经分配的句柄数量,第三个数字是系统总共可分配的句柄数量。如果第一个数字接近第三个数字,那么就要小心了。

夜莺的内置告警规则中,有针对 categraf 的机器指标的告警规则,其中就有文件句柄使用率的告警:

linux_sysctl_fs_file_nr / linux_sysctl_fs_file_max > 0.9

另外,如果你使用了 categraf 的 procstat 进程监控插件,并且打开了 gather_more_metrics 中的 limit,还会采集到 procstat_rlimit_num_fds_soft 指标,夜莺的内置规则中还有这么一条告警规则:

procstat_rlimit_num_fds_soft < 2048

这是采集进程的软句柄限制,如果软句柄限制过小,就告警。通常,小于 2048,大概率就是运维人员忘记做操作系统的参数调优了。

如上知识,希望对你有帮助。文末请允许我插播一个小广告。本人创业两年了,我们公司的业务如下,如果你有这方面的需求,欢迎联系我们做产品技术交流哈。

🎯 关于快猫星云

快猫星云是一家云原生智能运维科技公司,由知名开源项目“夜莺(Nightingale)”的核心开发团队组成,创始团队均来⾃阿⾥、百度、滴滴等互联⽹公司。夜莺是一款开源云原生监控工具,是中国计算机学会接受捐赠并托管的第一个开源项目,在GitHub上有超过8000颗星,迭代发布了超过100多个版本,上百位社区贡献者,是国内领先的开源可观测性解决方案。

快猫星云以开源夜莺为内核打造的“Flashcat平台”,是国内顶级互联⽹公司可观测性实践的产品化落地,致力于让可观测性技术更好的服务企业,保障服务稳定性。Flashcat 平台具有以下特点:

  • 统一采集:采用插件化思路,内置集成上百种采集插件,服务器、网络设备、中间件、数据库、应用、业务,均可监控,开箱即用。
  • 统一告警:支持几十种数据源对接,收集各类监控系统的告警事件,进行统一的告警收敛、降噪、排班、认领、升级、协同,大幅提升告警处理效率。
  • 统一观测:将 Metrics、Logs、Traces、Events、Profiling 等多种可观测性数据融会贯通,并预置行业最佳实践,既提供全局业务视角、技术视角的驾驶舱,也提供层层下钻的故障定位能力,有效缩短故障发现和定位时间。

快猫星云,让可观测性数据更有价值!
https://flashcat.cloud/

posted @ 2024-04-03 15:20  IT运维监控  阅读(117)  评论(0编辑  收藏  举报