linux服务器句柄数限制需分用户级、systemd服务级、系统级三层配置：用户级改/etc/security/limits.conf并重登录；systemd服务需修改unit文件或system.conf后reload；系统级调大/proc/sys/fs/file-max及sysctl.conf。

Linux 服务器句柄数限制修改不是改一个地方就能全局生效，得按层级分别处理：用户级、系统级、systemd 服务级，三者互不覆盖，缺一不可。

查清当前限制值

动手前先确认现状，避免盲目配置：

• 当前 shell 的软/硬限制：ulimit -n（软限）、ulimit -Hn（硬限）
• 系统总文件句柄上限：cat /proc/sys/fs/file-max
• 某个进程实际用了多少句柄：ls -l /proc//fd | wc -l
• 当前系统是否启用 pam_limits：grep -v '^#' /etc/pam.d/common-session | grep pam_limits.so（Ubuntu/Debian）或检查 /etc/pam.d/system-auth（CentOS/RHEL）

用户级限制（登录用户 & shell 子进程）

这是普通服务（如手动启的 Java、Python 进程）生效的关键。只配 soft 不行，必须同时提升 hard limit，否则 ulimit -n 会失败。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

• 编辑 /etc/security/limits.conf，追加两行（推荐用具体用户名替代 *，避免被覆盖）：
  youruser soft nofile 65535
  youruser hard nofile 65535
• 确保 PAM 加载了 limits 模块：/etc/pam.d/common-session 中有 session required pam_limits.so
• 必须重新登录（SSH 断开重连，或图形界面登出再进），仅新开终端窗口无效
• 验证：ulimit -n 输出应为 65535，且 ulimit -Hn 也需 ≥65535

systemd 服务限制（nginx、redis、docker 等 systemctl 启动的服务）

/etc/security/limits.conf 对它们完全无效——因为 systemd 进程本身不走 PAM 登录流程。

• 单个服务配置：编辑其 unit 文件，如 /etc/systemd/system/nginx.service，在 [Service] 下添加：
  LimitNOFILE=65535
• 全局默认配置：修改 /etc/systemd/system.conf，取消注释并设：
  DefaultLimitNOFILE=65535
• 配置后必须执行：sudo systemctl daemon-reload，再重启对应服务
• 验证方式：systemctl show nginx | grep LimitNOFILE 或 cat /proc/$(pgrep nginx)/limits | grep "Max open files"

系统总句柄池（所有进程共享的底层上限）

单个进程开了 65535，但系统总池子只有 10 万，高并发时照样报错。这个值必须同步放大。

• 临时生效：sudo sysctl -w fs.file-max=2097152
• 永久生效：在 /etc/sysctl.conf 中添加：
  fs.file-max = 2097152
• 立即加载：sudo sysctl -p
• 可选增强：fs.nr_open = 2097152（单进程最大可设上限，不能超 file-max）