查清 Squid 真实的文件描述符上限
在改动 PAM 设置或照搬容量方案里的固定 nofile 值之前，先读取正在运行的代理进程的实际限制。
在相信登录 shell 里的 ulimit -n 之前，先检查正在运行的守护进程。对使用 squid.service 的安装，先执行：
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service用真实的进程 ID 读取 /proc/PID/limits。多进程部署时，也要查看对应的 worker。配置里保存的值并不能证明该进程继承了这个值。
| 控制项 | 作用范围 |
|---|---|
Shell 的 ulimit 与 PAM 的 limits.conf | shell 的后代进程，或真正使用 PAM 设置的会话 |
systemd 的 LimitNOFILE= | 在该服务资源策略下启动的进程 |
Squid 的 max_filedescriptors（在支持的情况下） | 操作系统约束之内的应用层上限 |
系统服务不会仅因为管理员改了文件就采纳 PAM 的修改。需要调整 systemd 上限时，应使用针对该服务的 drop-in。Squid 的文档说明，max_filedescriptors 修改后必须重启；若保持未设置，则继承操作系统的软限制。
按描述符数量而不是用户数量来估算上限。客户端可能同时持有多个套接字，出站连接、日志和辅助管道同样消耗描述符。提高上限只是允许更多消耗，并不会立刻为每个可能的描述符预留固定内存。旧的“每套接字内存占用”估算和 65,535 都不是通用的容量要求，也不是 Linux 的上限。
改完服务后，把新进程的限制与预期值对比。如果故障出现在远低于该值的位置，应去排查真正被耗尽的资源。