shell的ulimit很高网关仍报too many open files，怎样核对服务进程实际限制

服务进程的文件描述符限制要从该进程取证，不能用交互shell的ulimit代替。同时统计当前fd与软限制，才能判断是否接近耗尽；提高限制以前还要排查泄漏和连接增长。

确认错误所在PID和进程

shell、登录会话、systemd unit与容器可能各自设置不同限制。交互终端显示65535，服务进程仍可能只有128。报错也不总是单进程软限制，还可能涉及系统级表或资源泄漏，因此应保留/proc/PID/limits与fd数量，而不是只截一条终端输出。

读取服务实际soft/hard而非shell值

样本把服务软限制设为合成128、已开120，得到八个余量；Linux分支另创建全新子进程，将它自己的RLIMIT_NOFILE限制为64并读回。父进程与系统服务不受改变。程序展示合成证据解析和真实受限子进程，明确区分两类输出。

采集fd数量时，枚举目录本身也可能临时打开描述符，因此小样本不应按差一个就认定泄漏。更有价值的是以同一身份、同一方法观察趋势，并关联流量与连接生命周期。软限制决定当前进程的实际可用上限，硬限制约束它能调到多高；两者都应留在取证记录里。

说明select兼容和内存成本再决定调参

真实排查可以按描述符类型观察文件、socket、管道是否单调增长，再复核连接池与关闭路径。不要直接把LimitNOFILE设为极大值掩盖泄漏；更高上限也意味着更大资源消耗空间。本文不对现有PID读取环境或私密文件，也不能由一个子进程演示确定生产报错根因。

适用范围：Linux实验证明仅临时子进程；Windows仅执行合成证据解析并标记未做资源限额实测，不盲给极大LimitNOFILE。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

跨平台运行可以复核合成余量，Linux执行还会返回native_child中的真实软限制。检查remaining为8，并确认子进程soft为64；shell_limit只是合成对照，不能代表运行机器的当前shell。真正接入现场证据时应记录准确PID及采集时间，防止服务重启以后把另一代进程的fd数量配到旧limits上。

Linux与Python3.8以上；使用本机Unix行为。程序只对自己创建的子进程、临时路径施加改变，不接受生产路径参数。

python3 -B run.py

阅读输出时，先按case.json中的任务逐项核对网关systemd文件描述符限制，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（WorkingDirectory影响相对路径；LimitNOFILE是进程限制，不能据交互shell推定服务值或盲目调高。）。

继续阅读：keepalive设成32为什么仍有上百上游连接，怎样区分闲置缓存与并发上限；网关修好配置还是提示start request repeated too quickly，怎样处理启动限额；大模型 API 超时与连接管理。