需同步调高ulimit -u至65535、pid_max至196608，并为systemd服务单独配置LimitNPROC；因ulimit -u限制进程+线程总数，Java等应用易触顶导致fork失败。
银河麒麟V10系统中运行Java微服务、达梦数据库或大量容器时，后台进程频繁被kill或启动失败，报“Resource temporarily unavailable”，说明当前用户级进程/线程总数限制（ulimit -u）已触顶，必须精准设置后台进程限制数量才能保障服务持续运行。
确认当前后台进程限制是否为瓶颈
先验证问题是否真出在用户级进程数限制上：执行 ulimit -u，若输出≤4096，而你的后台服务需同时维持2000+线程（如Spring Boot + Netty），则大概率是此层卡死。注意：【ulimit -u实际限制的是进程+线程总数】，不是纯进程数——Java应用每个线程都占一个PID，极易撞墙。
再交叉验证：执行 ps -eLf | wc -l 统计全系统线程数，若该值持续接近 ulimit -u 输出值，说明当前用户会话下存在线程泄漏或并发失控，而非系统全局资源枯竭。
临时提升当前会话的后台进程限制
这一步操作起来很简单，直接在终端敲命令就行，适合紧急恢复或快速验证配置效果。
执行 ulimit -u 65535，将软限制设为65535。
若提示“cannot modify limit: Operation not permitted”，说明硬限制未放开，需用root权限执行：sudo ulimit -Hn 65535。
【此操作仅对当前终端及其所有子进程生效，关闭窗口或新建SSH会话后立即失效】。
永久配置用户级后台进程限制
生产环境必须做这步，否则每次登录都要重设，且systemd服务完全不读这个值。
第一步：用root权限编辑limits配置文件：sudo nano /etc/security/limits.conf。
第二步：在文件末尾追加两行（以通配所有用户为例）：
* soft nproc 65535
* hard nproc 65535
第三步：检查PAM模块是否启用——执行 grep "pam_limits.so" /etc/pam.d/common-session，若无输出，需手动添加一行：session required pam_limits.so。
第四步：退出当前会话，重新SSH登录或console login，再执行 ulimit -u 确认输出为65535。
为systemd管理的后台服务单独设限
nginx、dmserver、postgresql等由systemd管理的服务，压根不读/etc/security/limits.conf，必须显式声明LimitNPROC才能真正控制其后台进程数量。
方法一：全局设置（影响所有service）
编辑 /etc/systemd/system.conf，取消注释并修改：DefaultLimitNPROC=65535
方法二：单服务定制（推荐用于数据库等关键服务）
运行 sudo systemctl edit DmService，在打开的空白文件中输入：[Service]LimitNPROC=65535
保存后执行 sudo systemctl daemon-reload → 再执行 sudo systemctl restart DmService。
同步调高内核PID上限（关键前提）
只改 ulimit -u 不碰 pid_max，等于给后台服务发了65535张车票，但火车站只建了32768个检票口——fork调用仍会失败并报“Resource temporarily unavailable”。
临时生效（重启失效）：执行 sudo sysctl -w kernel.pid_max=196608。
永久生效：执行 echo "kernel.pid_max = 196608" | sudo tee -a /etc/sysctl.d/99-pidmax.conf；再执行 sudo sysctl --system。
【x86_64架构下，196608是安全且高效的推荐值；设为4194304虽可行，但可能增加调度器开销】。
