统信UOS需分层调高文件描述符限制：①临时设为65535验证；②永久修改/etc/security/limits.conf并启用pam_limits.so；③增大内核fs.file-max；④配置systemd DefaultLimitNOFILE或单服务LimitNOFILE；⑤逐层验证各上下文生效情况。
统信UOS系统中运行Nginx、Redis或自研后端服务时，若频繁出现“Too many open files”错误、连接数无法提升、进程因资源耗尽被kill，说明当前ulimit软硬限制过低，必须分层调整用户级、系统级和systemd服务级限制才能真正生效。
临时修改当前会话限制
这一步操作起来很简单，直接在终端里敲命令就行，适用于快速验证配置是否合理或紧急调试场景。
执行
立即验证：【ulimit -n输出必须等于65535，否则说明当前用户权限不足或shell环境异常】
永久修改用户级软硬限制
该配置通过PAM模块加载，覆盖所有登录会话（包括图形界面启动的应用），是UOS中最基础且必须完成的一环。
第一步：用sudo权限编辑limits配置文件：sudo nano /etc/security/limits.conf
第二步：在文件末尾新增两行，分别设置软限制与硬限制：
* soft nofile 65535
* hard nofile 65535
第三步：检查PAM是否启用limits模块——打开/etc/pam.d/common-session，确认存在session required pam_limits.so这一行；【若不存在，手动追加并保存，否则配置永不生效】
第四步：退出当前图形会话并重新登录，或新开终端执行ulimit -n验证值是否已更新。
同步调大系统级文件句柄总量
用户级限制不能超过内核允许的全局上限，否则即使limits.conf写得再高也卡死在默认值（通常为1024或4096）。
编辑内核参数文件：sudo nano /etc/sysctl.conf
追加一行：fs.file-max = 2097152
立即加载新参数：sudo sysctl -p
验证生效：cat /proc/sys/fs/file-max 输出应为2097152
适配systemd托管的服务进程
统信UOS基于systemd，nginx、redis、tomcat等服务默认不读取limits.conf，必须单独配置，否则服务启动时仍沿用默认限制。
方法一：全局配置所有systemd服务
编辑systemd主配置：sudo nano /etc/systemd/system.conf
取消注释并修改DefaultLimitNOFILE=65535
执行sudo systemctl daemon-reexec重载配置
方法二：为单个服务精准控制
例如针对nginx，编辑其单元文件：sudo nano /lib/systemd/system/nginx.service
在[Service]段落下添加LimitNOFILE=65535
执行sudo systemctl daemon-reload && sudo systemctl restart nginx
逐层验证是否真正生效
不同层级限制需在对应上下文中验证，缺一不可。
① 当前shell会话：ulimit -n
② 系统全局上限：cat /proc/sys/fs/file-max
③ 目标服务进程（以nginx主进程PID为例）：cat /proc/$(pgrep -f 'nginx: master process' | head -n1)/limits | grep "open files"
