立即执行ulimit -n 65535临时提升当前会话限制；永久配置需修改/etc/security/limits.conf添加* soft/hard nofile 65535，重启图形会话生效；同步调大fs.file-max至2097152并sysctl -p加载；systemd服务须配置defaultlimitnofile或limitnofile；最后逐层验证shell、系统及进程级限制是否均为65535。
您在统信UOS中运行Nginx、Redis或自研高并发服务时，突然收到“Too many open files”错误，进程崩溃退出——这说明系统当前打开文件数限制已触顶，必须立即调整最大文件限制。
临时提高当前会话限制
这一步操作起来很简单，直接在终端里执行命令就行，仅对当前终端及其启动的子进程生效，适合快速验证是否是句柄不足导致的问题。
执行：ulimit -n 65535
验证是否成功：ulimit -n → 输出应为 【65535】。若仍显示1024或4096，说明当前shell受限于PAM策略，需跳过此步直接进入永久配置。
永久修改用户级最大打开文件数
该设置通过PAM模块加载，覆盖所有登录会话（包括图形界面启动的应用），是绝大多数服务实际生效的层级。
第一步：编辑限制配置文件sudo nano /etc/security/limits.conf
第二步：在文件末尾新增两行（注意空格不能用Tab替代，必须是英文空格）：* soft nofile 65535* hard nofile 65535
第三步：保存退出，【必须重新登录或重启图形会话（Ctrl+Alt+Backspace 或注销再登录）才能生效】。仅重启终端无效，因为图形环境进程不读取新limits。
同步调大系统级文件句柄总量
用户级限制不能超过内核允许的全局上限，否则硬限制会被自动截断为fs.file-max值。若只改limits.conf却不调大此项，65535可能实际被压到默认的几十万以下。
编辑内核参数：sudo nano /etc/sysctl.conf
追加一行：fs.file-max = 2097152
立即加载：sudo sysctl -p
验证：cat /proc/sys/fs/file-max → 输出应为 【2097152】
适配systemd托管的服务进程
nginx、redis、mysql等服务由systemd启动，默认完全忽略/etc/security/limits.conf，必须单独配置systemd的DefaultLimitNOFILE。
方法一：全局启用
编辑：sudo nano /etc/systemd/system.conf
取消注释并修改：DefaultLimitNOFILE=65535
方法二：单服务覆盖（推荐用于关键服务）
创建覆盖目录：sudo mkdir -p /etc/systemd/system/nginx.service.d
新建配置：echo "[Service]\nLimitNOFILE=65535" | sudo tee /etc/systemd/system/nginx.service.d/override.conf
重载配置：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" | head -n1)/limits | grep "Max open files" → 输出第二列（soft limit）和第三列（hard limit）都应为65535。
