先用 lsof 和 /proc/pid/fd 定位高句柄进程，再用 ulimit -n 临时提升当前会话限制；永久修复需按 systemd 规则配置 limits，避免仅改 limits.conf 失效。
Linux 进程报 Too many open files 怎么立刻查和临时修复
这不是配置没生效，而是当前进程或用户已突破系统级文件句柄限制。先别改配置，先定位谁在吃句柄。
常用排查命令：
-
lsof -nPi | awk '{print $2}' | sort | uniq -c | sort -nr | head -10—— 查占用句柄最多的 PID -
ls /proc/<code>PID/fd | wc -l —— 精确看某进程打开了多少个 fd（PID替换为实际值） -
cat /proc/<code>PID/limits | grep "Max open files" —— 看该进程实际生效的软硬限制
临时提升：对正在运行的进程无效；但可立刻提升当前 shell 的限制，供后续启动的子进程继承：ulimit -n 65536。注意这仅对当前会话有效，且不能超过硬限制（ulimit -Hn 查）。
永久修改用户级 ulimit 需绕过 systemd 用户 session 限制
在 /etc/security/limits.conf 里加 username soft nofile 65536 和 username hard nofile 65536 是常见做法，但对 systemd 启动的服务（如 systemctl --user start xxx）往往不生效 —— 因为 systemd 会忽略 limits.conf。
正确做法是：
- 对用户级服务：编辑
~/.config/systemd/user.conf，取消注释并修改DefaultLimitNOFILE=65536 - 对系统级服务：在 service 文件中加
LimitNOFILE=65536（放在[Service]段） - 若用
sudo启动，还需确认sudoers中未重置 limits（检查是否有Defaults env_reset且未显式保留ulimit）
改完记得重启对应 systemd 用户实例：systemctl --user daemon-reload && systemctl --user restart xxx。
fs.file-max 是全局上限，不是 per-process 限制
fs.file-max 控制整个内核能分配的最大文件句柄数，和单个进程的 ulimit -n 是两层机制。它只在总量耗尽时触发（比如上万进程同时打开数千文件），日常遇到的 Too many open files 基本都是进程级 ulimit 卡住，而非这个值太小。
调整它需谨慎：
- 临时改：
sysctl -w fs.file-max=2097152 - 永久改：写入
/etc/sysctl.conf，加一行fs.file-max = 2097152 - 注意：该值过高可能增加内核内存开销（每个 fd 约占 1KB 内核空间），一般 2M 足够支撑多数高并发服务
改完不用重启，但需确保 sysctl -p 生效，且 sysctl fs.file-max 输出与预期一致。
Golang / Python 程序里没关 os.File 或 io.Closer 是高频泄漏源
语言运行时不会自动回收未关闭的文件句柄，尤其在异常路径、循环体、defer 嵌套错误时极易漏关。现象是：进程 fd 数缓慢上涨，lsof -p <code>PID 里出现大量 REG 或 pipe 类型句柄，且长时间不释放。
关键检查点：
- Golang：所有
os.Open、os.Create、os.OpenFile必须配对Close()；用defer f.Close()时，确保f不是 nil（否则 panic） - Python：优先用
with open(...)；避免裸调open()后忘记.close()；检查subprocess.Popen是否设置了close_fds=True（默认 True，但旧版本或显式设 False 会泄漏） - 通用技巧：在程序启动时打印
len(os.listdir('/proc/self/fd'))（Python）或syscall.Getrlimit(syscall.RLIMIT_NOFILE)（Go），便于 baseline 对比
别依赖 GC —— 文件句柄不是内存，GC 不管它。
