最准方式是读/proc/[pid]/limits，如cat /proc/1234/limits | grep "max open files"，第二列为软限制（进程实际可用上限），第三列为硬限制（仅root可调高），该值反映内核为该进程维护的真实快照，不受shell或limits.conf影响。
直接看当前 shell 的软限制用 ulimit -a
这是最常用、最快捷的方式，ulimit -a 输出的是你当前终端会话里所有资源的**软限制值**，也就是进程实际能用的上限。它不区分软硬，只告诉你此刻生效的值。
常见陷阱：输出里 open files (-n) 1024 表示每个进程最多打开 1024 个文件描述符；max user processes (-u) 4096 是该用户能启动的总进程数。但注意，这些只是 shell 层面的设置，和 nginx、redis 这类 systemd 启动的服务无关——它们可能完全没继承这个值。
-
ulimit -n单独查打开文件数软限制 -
ulimit -u查最大进程数软限制 -
ulimit -s查栈大小（单位是 KB，不是字节） -
ulimit -c查 core 文件大小（单位是 512 字节块，ulimit -c 0才是禁用）
确认某个运行中进程的真实限制用 /proc/$pid/limits
这才是最准的依据。cat /proc/1234/limits 显示的是内核为 PID 1234 进程维护的实时快照，包括软硬限制、单位、是否 unlimited，完全不受你当前 shell 影响。
关键点：输出里 Max open files 那一行的第二列（Soft Limit）才是该进程真正能用的值。如果你在日志里看到 Too many open files，必须查这个，而不是 ulimit -n。
- 普通用户只能读自己进程的
/proc/$pid/limits，其他用户会报Permission denied - systemd 服务的限制可能被
LimitNOFILE=覆盖，此时即使改了ulimit也没用 - 输出中
unlimited不等于没限制，可能是硬限制极高，或被 cgroup/systemd 拦截了
查系统级全局上限用 /proc/sys/fs/file-max
ulimit 和 /proc/$pid/limits 都是进程级或用户级的，而整个系统的文件描述符总量由内核参数控制，查 cat /proc/sys/fs/file-max 就行。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
这个值决定了全系统最多能分配多少文件句柄，和单个进程无关。如果大量进程都卡在 open files 限制，但每个进程的 soft limit 已调高，就得看这个值够不够——比如默认 8192 在高并发服务下往往不够。
-
cat /proc/sys/fs/file-nr可看当前已分配/未使用/最大可用的文件句柄数 - 修改它需要 root 权限：
echo 65536 > /proc/sys/fs/file-max（临时），或写入/etc/sysctl.conf - 这个参数和
ulimit -n是两层机制，一个管全局，一个管单进程
验证持久化配置是否生效得看 /etc/security/limits.conf 和登录会话
/etc/security/limits.conf 里的设置只对**PAM 登录会话**生效，比如 ssh 登录、图形界面登录。它不会影响 systemd 直接启动的服务、cron 任务、或已运行的后台进程。
常见错误：改完 limits.conf 就立刻去跑 ulimit -n，发现没变——因为你没新开一个登录 shell。必须重新登录，或者用 su - $USER 切换到新会话。
- 格式要严格：
username soft nofile 65536，中间不能多空格，soft/hard不能写错 - 通配符
*和@group也受 PAM 加载顺序影响，/etc/security/limits.d/*.conf会覆盖主文件 - systemd 服务绕过 limits.conf，得在 service unit 文件里显式写
LimitNOFILE=65536
真正容易被忽略的是：同一个进程的限制可能来自多个源头叠加——shell 继承自登录会话，登录会话读 limits.conf，而 systemd 服务又无视 limits.conf 改走自己的 unit 配置。查问题时，必须先锁定目标进程，再一层层往回追溯它的启动路径和限制来源。
