银河麒麟V10中“Resource temporarily unavailable”因用户级进程数限制（ulimit -u）与内核PID池（pid_max）不匹配导致；需同步调高ulimit -u至65535并设pid_max为196608，且systemd服务须单独配置LimitNPROC。

银河麒麟V10系统运行Java微服务或大量容器时频繁报“Resource temporarily unavailable”，说明当前用户级进程数限制已触顶；该限制由ulimit -u控制，但仅调高它而不同步扩大内核PID池（pid_max）会导致fork失败，必须双轨并行调整。

确认当前用户进程限制是否为瓶颈

先验证问题是否真出在用户级：执行，若输出≤4096，而应用需启动3000+线程（如Spring Boot + Netty），则大概率是此层卡死。注意：Linux中线程也占用独立PID，【ulimit -u实际限制的是进程+线程总数】，不是纯进程数。

再交叉验证：执行统计全系统线程数，若该值接近输出，说明当前用户会话下存在线程泄漏或并发失控，而非系统全局资源枯竭。

临时提升当前会话的nproc限制

这一步操作起来很简单，直接在终端敲命令就行，适合紧急恢复或快速验证配置效果。

执行，将软限制设为65535。

若提示“cannot modify limit: Operation not permitted”，说明硬限制未放开，需用root权限执行：。

【此操作仅对当前终端及其所有子进程生效，关闭窗口或新建SSH会话后立即失效】。

永久配置用户级nproc限制

生产环境必须做这步，否则每次登录都要重设，且systemd服务完全不读这个值。

第一步：用root权限编辑limits配置文件：。

第二步：在文件末尾追加两行（以通配所有用户为例）：
* soft nproc 65535
* hard nproc 65535

第三步：检查PAM模块是否启用——执行，若无输出，需手动添加一行：。

第四步：退出当前会话，重新SSH登录或console login，再执行确认输出为65535。

同步调高内核PID上限（关键前提）

只改不碰，等于给用户发了65535张车票，但火车站只建了32768个检票口——fork调用仍会失败并报“Resource temporarily unavailable”。

方法一：临时生效（重启失效）
执行。

方法二：永久生效
执行；
再执行重载配置。

【x86_64架构下，196608是安全且高效的推荐值；设为4194304虽可行，但可能增加调度器开销】。

为systemd服务单独配置LimitNPROC

nginx、dmserver、postgresql等由systemd管理的服务，压根不读/etc/security/limits.conf，必须显式声明。

方法1：全局设置（影响所有service）
编辑

/etc/systemd/system.conf，取消注释并修改：
DefaultLimitNPROC=65535

方法2：单服务定制（推荐用于数据库等关键服务）
执行，输入：

[Service]
LimitNPROC=65535

执行，再重启对应服务。