最准确的方式是直接查看 /proc/$pid/limits，它反映内核为该进程维护的真实软硬限制快照，不依赖 shell 会话或配置文件加载状态；每行含资源名、软限制、硬限制及单位，如“max open files 1024 65536 files”。
直接看 /proc/$pid/limits 最准
这是唯一能确认某个进程**此刻真实生效限制**的方式，不依赖 shell 会话、PAM 加载状态或配置文件是否被读取。内核为每个进程维护一份独立快照，/proc/$pid/limits 就是它对外暴露的只读视图。
常见错误现象：改了 ulimit -n 65536，但服务日志仍报 “too many open files”，一查 /proc/$pid/limits 发现还是 1024 —— 说明新限制根本没落到该进程上。
- 用
ps aux | grep myapp找到 PID，再执行cat /proc/1234/limits - 输出里每行含三列：
Limit（资源名）、Soft Limit（当前软限）、Hard Limit（对应硬限），单位明确写在末尾，如files、bytes、processes -
unlimited不等于“没限制”，可能是硬限设得太高，也可能是被 cgroup 或 systemd 拦截了，需结合systemctl show myapp.service | grep LimitNOFILE排查 - 普通用户只能查看自己启动的进程，看别人 PID 会报
Permission denied；root 可全量查看
prlimit 查 + 改运行中进程的限制
prlimit 是唯一能在不重启进程的前提下修改 /proc/$pid/limits 的工具，但它权限和行为约束很紧，不是所有场景都适用。
容易踩的坑：对 systemd 启动的服务，prlimit 改完可能立刻被拉回原值 —— 因为 DefaultLimitNOFILE 或 service unit 里的 LimitNOFILE= 会覆盖运行时修改。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 查某进程当前限制：
prlimit -p 1234 - 把软硬限制都设为 16384：
prlimit -p 1234 --nofile=16384:16384 - 普通用户只能降低自己的软限制，或把软限提至当前硬限范围内；提高硬限必须是 root
- 子进程不会继承父进程被
prlimit修改后的限制，除非显式调用fork()+exec()
别信 echo > /proc/$pid/limits
这个路径是只读虚拟文件，echo "Max open files=65536:65536" > /proc/1234/limits 绝对不行 —— 内核禁止写入，会报 Invalid argument 或 Permission denied。
有人看到旧文档这么写，大概率混淆了早期内核（2.6.32 之前）的调试接口，或把可写的 /proc/sys/ 参数当成了 /proc/$pid/ 下的。
-
/proc/$pid/limits是状态出口，不是控制接口 - 真正生效的只有
prlimit、进程启动前由内核/初始化系统设定的值，或通过setrlimit(2)系统调用由进程自己调整（在硬限范围内） - 想持久化？得改
/etc/security/limits.conf（登录会话）或 systemd service 的LimitNOFILE=（服务管理）
ulimit -a 只反映当前 shell 会话
它告诉你的是“这个终端里新起的进程默认会拿到什么限制”，不是目标进程的实际值。常被误当作进程级诊断依据。
典型误用：在终端里执行 ulimit -n 得到 65536，就以为 nginx worker 进程也拿到了 —— 实际上 nginx 是 systemd 启动的，它的限制由 LimitNOFILE= 控制，跟你的 shell 无关。
-
ulimit -n查当前软限，ulimit -Hn查当前硬限 -
ulimit -a输出里unlimited表示软限未设上限，但硬限可能仍是 1024，进程仍会被卡住 - 非登录方式启动的服务（systemd、docker、supervisord）基本不走 PAM 的
limits.conf，ulimit对它们无效
cat /proc/$pid/limits 确认目标进程的真实值，再反推该从哪一层改 —— 是 shell 会话、systemd unit、还是容器 runtime 的限制配置。别在错的地方调参数。
