Linux ulimit 怎样判断文件句柄上限

Linux 判断文件句柄上限时，先用 ulimit -Sn 和 ulimit -Hn 分别读取当前 Bash 的软、硬限制；判断后台服务则应读取目标 PID 的 /proc/PID/limits，而不是拿登录终端的值代替。再结合 /proc/PID/fd 的描述符数量及系统级 file-nr、file-max，才能判断压力在哪一层。

这里的“句柄”通常指文件描述符，不只包括普通文件，还包含 socket、管道等。以下命令供读者在 Linux 上按实际 PID 执行；本文未运行示例，也不展示虚构终端结果。

先读软硬上限，不把登录终端当成服务

# 在 Bash 中只读取当前 Shell 的限制，不传入设置值
ulimit -Sn
ulimit -Hn
# 查看当前 Bash 的全部软限制，便于确认资源类别
ulimit -Sa

软限制是当前生效的资源约束，硬限制是普通进程可以调整软限制的上界。普通进程不能随意提高硬限制。Bash 查询时不写 -H 通常读软限制，显式写 -S、-H 更利于交接；设置限制时省略这两个选项却可能同时改变两者，所以不要把查询命令机械地加一个数值就当作修复。

子进程继承父进程资源限制，exec 也会保留它们。但由服务管理器启动的进程并不是当前登录 Bash 的子进程；同一账号也不保证限制相同。Bash 官方手册地址：https://www.gnu.org/s/bash/manual/html_node/Bash-Builtins.html。内核资源限制语义见 getrlimit 手册。

用 PID 对齐限制与当前描述符数量

# 12345 只是占位值，先替换为已确认身份的目标进程
target_pid=12345
# Max open files 行同时给出软限制、硬限制和单位
awk '/^Max open files / {print}' "/proc/$target_pid/limits"
# 在具备目录枚举权限时，查看描述符编号；不是递归扫描文件系统
ls -1U "/proc/$target_pid/fd"

不要通过“进程名相似”就认定 PID 正确。主进程、worker、容器内外 PID 可能不同；每个实际工作进程都需要对应自己的记录。/proc/PID/fd 中每个编号代表一个已打开的描述符，链接可指向文件、socket、pipe 或匿名内核对象。目录读取权限和进程生命周期都会影响采样。

严格地说，RLIMIT_NOFILE 限制的是可新分配描述符编号的范围，上限值比最大允许编号大一。描述符存在空洞或应用曾主动降低软限制时，“上限减数量”不应被当作精确剩余容量。用数量与软限制的比值观察压力可以，但要结合错误与变化趋势。字段定义见 proc_pid_limits 和 proc_pid_fd。

把进程上限和系统总量分开

# 只读系统范围文件句柄指标，不修改内核参数
cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-max
# 查看进程硬限制能够设置到的内核边界
cat /proc/sys/fs/nr_open

file-nr 依次报告已分配、已分配但未使用、最大文件句柄数；现代 Linux 的第二项常为零，并不表示没有空闲容量。file-max 是系统范围的文件句柄分配上限，nr_open 则约束进程可设置的描述符硬限制。它们都不是“当前服务已经打开多少文件”。内核定义见 /proc/sys/fs 文档。

进程描述符耗尽常关联 EMFILE；系统范围分配耗尽常关联 ENFILE。应保留应用实际 errno 和时间，不能只凭含糊的“Too many open files”转述决定调整哪层。重复描述符和共享打开文件对象还意味着进程描述符数量之和，不必等于系统文件句柄计数。

把只读采样放进巡检任务

如果需要周期观察，采样输入应是明确的 PID 或服务实例，使用最小必要读取权限。以下 Bash 片段只产生一次报告，不改限制、不重启服务。它保留目录读取错误，避免把失败管道末尾的零行数误当成“占用为零”。

#!/usr/bin/env bash
# 单次只读采样；由外部调度器决定频率，不在脚本内无限循环
set -u
target_pid=${1:-}
case "$target_pid" in
  ''|*[!0-9]*|0) printf '%s\n' '请输入有效的正整数 PID' >&2; exit 2 ;;
esac
proc_dir="/proc/$target_pid"
# 读取失败作为未知状态上报，不替换成零
if ! limit_row=$(awk '/^Max open files / {print $4, $5}' "$proc_dir/limits"); then
  printf '%s\n' '无法读取进程限制，可能是权限或进程退出' >&2
  exit 3
fi
if [[ -z "$limit_row" ]]; then
  printf '%s\n' '未找到文件描述符限制字段' >&2
  exit 3
fi
# 先确认枚举成功再计数，避免 ls 失败后 wc 仍输出零
if ! fd_rows=$(LC_ALL=C ls -1U "$proc_dir/fd"); then
  printf '%s\n' '无法枚举描述符，采样状态未知' >&2
  exit 4
fi
fd_count=0
if [[ -n "$fd_rows" ]]; then
  fd_count=$(printf '%s\n' "$fd_rows" | wc -l)
fi
# soft_hard 按软、硬顺序输出；计数只是瞬时近似值
printf 'pid=%s soft_hard=%s fd_count=%s\n' "$target_pid" "$limit_row" "$fd_count"

脚本成功表示这次读取完成，不表示服务健康。文件系统枚举不是原子快照：期间可打开或关闭描述符，PID 也可能退出并被复用。生产采集器应同时记录主机、采样时间、进程启动身份以及采集状态，PID 身份变化后不要续接旧进程曲线。只有正确取得数值并确认对象一致，才进入容量判断；失败样本应标为缺失，而不是补零。

遇到不足或读取失败时怎样处理

占用随请求上涨后回落，可能是正常并发；负载下降后仍持续单向上涨，则应排查文件、连接或管道是否按生命周期关闭。一次高值不能证明泄漏。阈值应结合并发峰值、连接池、日志文件及预留余量制定，不照搬一个对所有服务通用的百分比。

确定软限制不足时，仍要评估程序兼容性和资源预算。尤其使用传统 select 的程序存在描述符编号边界，盲目提高上限可能引入另一类问题。systemd 服务应核对 LimitNOFILE 与目标进程实际 limits，不能只改登录 Shell；读取配置是定位依据，实际修改和重启应走批准的变更流程。systemd 官方手册地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html。

权限不足时使用被授权的采集账号或管理员渠道，不建议为了读目录就广泛放宽 procfs 或进程权限。进程重启后重新定位 PID，检查新进程的实际限制；单纯看到配置文件出现新数字，不代表正在运行的进程已经改变。

交接记录和常见疑问

通知信息至少包含主机、服务或实例、PID 与启动身份、采样时间、软硬限制、描述符数量、系统范围指标和采集状态。没有实际错误时，将告警表述为“接近容量边界”，不要直接断言“已经泄漏”或“系统句柄耗尽”。修复前后保留同口径样本，便于判断调整是否作用于正确的进程。

ulimit -n 很大，服务为什么仍报错？它读到的是当前 Shell；目标服务可能来自另一启动入口，也可能已耗尽自身软限制。先读目标 PID，而不是继续提高终端数值。

同一个用户的限制为什么不同？资源限制是进程属性。不同父进程、服务配置或应用启动后的调整，都可能让同账号的进程采用不同值。

目录里只有几百项，是否肯定安全？不能。瞬时数量不是峰值，也不能排除采样对象错误、跨进程传递描述符等其他限制。先确认对象和错误类别，再结合持续观测下结论。

最小判断顺序是：明确进程身份，读取软硬限制，观察描述符数量，再对照系统范围指标和实际错误。ulimit 是入口，不是所有服务的统一答案。