关于 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=simpleExecStart=/opt/categraf/categraf
WorkingDirectory=/opt/categrafRestart=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 等多种可观测性数据融会贯通，并预置行业最佳实践，既提供全局业务视角、技术视角的驾驶舱，也提供层层下钻的故障定位能力，有效缩短故障发现和定位时间。