麒麟os上解决“too many open files”需分层配置ulimit：先验证当前限制，再通过临时命令、pam limits.d、systemd系统级及服务单元文件四级方式永久调优，并验证生效。

如果您在麒麟操作系统上运行数据库或高并发服务时遇到“Too many open files”错误，或是服务因资源限制异常退出，则很可能是系统级 ulimit 设置未适配实际负载需求。以下是针对麒麟OS的 ulimit 资源限制配置进阶方法：

一、验证当前限制状态

准确掌握当前生效的限制值是调优前提。系统存在会话级、用户级、系统级三重限制，需逐层确认其实际生效值。

1、查看当前 shell 会话的文件描述符软硬限制：ulimit -n

2、查看当前用户的最大可打开文件数上限：cat /proc/$(pgrep -u $USER | head -1)/limits | grep "Max open files"

3、检查系统全局文件句柄总量上限：cat /proc/sys/fs/file-max

4、确认 PAM limits 模块是否已启用：grep -q "pam_limits.so" /etc/pam.d/common-session && echo "enabled" || echo "disabled"

二、临时提升限制（当前会话有效）

该方式适用于快速验证、调试或应急场景，无需重启、不修改配置文件，但会话结束即失效。

1、以 root 权限临时设置当前会话的软硬限制均为 65535：sudo ulimit -n 65535

2、若需同时调整核心文件大小限制（避免 coredump 失败），执行：sudo ulimit -c unlimited

3、验证是否生效：ulimit -n 应返回 65535

三、永久生效配置（推荐生产环境使用）

通过 PAM limits 机制实现用户登录即加载预设限制，覆盖所有子进程，是麒麟OS V10 SP2/SP3 官方推荐的持久化方案。

1、编辑系统级 limits 配置文件：sudo vim /etc/security/limits.d/kylin-ulimit.conf

2、写入以下内容（以 dmdba 用户为例，按需替换用户名）：dmdba soft nofile 65536

3、写入硬限制行：dmdba hard nofile 65536

4、为 systemd 托管的服务补充内核参数（防止被覆盖）：echo "DefaultLimitNOFILE=65536" | sudo tee -a /etc/systemd/system.conf

5、重载 systemd 配置并重启用户会话：sudo systemctl daemon-reload && sudo systemctl restart systemd-logind

四、针对 systemd 服务的独立限制配置

当服务由 systemd 直接管理（如达梦数据库 DmService、OceanBase obd cluster）时，全局 limits.conf 可能不生效，必须在 service 单元文件中显式声明。

1、查找对应服务单元文件路径：systemctl show -p FragmentPath .service

2、编辑该文件（或创建 drop-in）：sudo systemctl edit .service

3、在打开的编辑器中添加如下内容：[Service]

4、插入限制项：LimitNOFILE=65536

5、保存退出后重载并重启服务：sudo systemctl daemon-reload && sudo systemctl restart .service

五、验证与排错关键点

配置完成后必须验证是否真正生效，常见失效原因包括 PAM 未启用、SSH 会话未重新登录、systemd 覆盖等。

1、确保 SSH 使用 PAM 认证：检查 /etc/ssh/sshd_config 中 UsePAM yes 已取消注释

2、强制重新建立完整登录会话：exit 当前终端，再用 ssh 或图形界面重新登录目标用户

3、验证服务进程实际限制：获取服务主进程 PID 后执行 cat /proc//limits | grep "Max open files"

4、若仍显示旧值，检查是否存在冲突配置：grep -r "nofile" /etc/security/limits.*，删除重复或低优先级配置文件