Linux如何设置ulimit -n超过100万？权限报错解决方法

你遇到的-bash: ulimit: open files: cannot modify limit: Operation not permitted报错，本质是触发了内核或系统配置层的多级硬限制，按以下步骤逐层调整即可：

• 先调整内核级全局参数
  两个核心内核参数决定了文件句柄的配置天花板：
  1. fs.file-max：系统全局可分配的文件描述符总数量，临时生效执行sysctl -w fs.file-max=2097152；永久生效则在/etc/sysctl.conf中添加fs.file-max = 2097152，执行sysctl -p加载配置。
  2. fs.nr_open：单个进程可持有文件描述符的最大硬上限，多数发行版默认值为1048576（刚好略超100万，是你之前卡到999999无法继续上调的核心原因之一），同样通过sysctl调整为2097152即可。
• 调整用户/进程级资源限制
  1. 编辑/etc/security/limits.conf，为运行服务的用户添加nofile配额配置，示例：

     # 给业务运行用户配置200万软/硬句柄上限
     appuser soft nofile 2000000
     appuser hard nofile 2000000
     # 若要对所有普通用户生效，可将用户名替换为*，注意root用户需单独配置
     root soft nofile 2000000
     root hard nofile 2000000
     

  2. 若你的服务通过systemd托管，仅修改limits.conf不生效，需要编辑对应服务的unit文件，在[Service]段添加LimitNOFILE=2000000，之后执行systemctl daemon-reload重启服务即可。
• 验证配置
  切换到运行服务的用户，执行ulimit -n确认返回值为你配置的数值；也可以通过cat /proc/<服务进程PID>/limits | grep "open files"查看进程实际生效的句柄上限。

注意：普通用户无权调高nofile的硬限制，所有配置调整需要root权限操作；调整时不要直接把上限设到内存无法支撑的数值，预留至少20%的冗余给系统其他进程。另外100万长连接场景下不建议使用一连接一线程的模型，每个线程默认数MB的栈内存会带来极高的开销，重连等待超时的逻辑也会造成大量线程空转浪费资源，优先选择epoll、io_uring这类事件驱动的IO模型实现。

• 控制内核资源开销：Linux下无论是普通文件、网络socket还是管道，都对应一个文件描述符，每个fd需要内核分配对应的结构体存储元数据、预留读写缓冲区内存，若不设上限，出现fd泄漏的异常进程会快速耗尽内核内存，导致整机宕机。
• 防范资源耗尽风险：无限制的fd分配权限会给bug程序、恶意代码留下攻击面，只要持续打开文件或建立网络连接，就能快速占满整机句柄资源，让其他正常进程无法打开日志、建立连接，直接触发拒绝服务。
• 兼容性历史遗留：早期UNIX系统用16位短整型存储文件描述符，天然上限为1024，尽管现代内核早已改用32位类型存储fd，默认仍保留较低的初始值，避免老应用因为fd数值超出预期范围出现逻辑错误。
• 实现资源配额隔离：通过「全局总上限-单进程上限-用户级上限」的分层限制机制，可以给不同业务、不同用户分配固定的资源配额，避免单个业务占满整机资源，影响其他服务运行。

内容的提问来源于stack exchange，提问作者GrafMetrics