故障分析：从Oracle数据库故障到Linux nproc算法

墨墨导读：本文来自墨天轮用户“你好我是李白”的投稿，使用root用户切换grid用户时报错-bash: fork: retry: Resource temporarily unava，这里记录故障处理全过程。墨天轮主页：https://www.modb.pro/u/3997

某日，朋友跟我讨论他巡检oracle数据库时遇到的一个情况，在使用root用户切换grid用户时报错-bash: fork: retry: Resource temporarily unavailable，一般这个报错都是因为/etc/security/limits.conf或/etc/security/limits.d/下相关用户nproc设置过小导致，但是定位一波三折，最终了解清楚了nproc参数生成、限制，将案例详细分享，供大家参考。

故障背景

巡检su – grid无法完成切换，报错

-bash: fork: retry: Resource temporarily unavailable。

环境介绍

操作系统为Redhat 6.8，数据库版本为Oracle 11.2.0.4 RAC。

初步分析，获取已存在进程limits环境设置

根据经验，上述报错一般为下面三个原因：

1. 用户的nproc达到限制，无法创建新的进程

2. 系统没有可分配的的pid，即进程号已经达到内核参数kernel.pid_max的限制

3. 系统可用内存低，新的进程无法申请到内存导致不能启动

下面我们一步一步排查：
检查用户已经存在进程limits设置与用户ulimit设置，检查如下：
如果已经有会话登陆grid用户，可以通过下面命令得到当前限制

如果已经无法正确切换grid用户，可以使用如下步骤得到限制

第一步：获取grid用户任意进程pid

第二步：使用cat查看/proc//limits获取限制设置

• 可以看到上述无论是已经登陆grid还是真实进程设置均为16384，设置均不算过低，grid用户一般不会占用这么多的process，那到底是由于bug还是其他原因耗尽了设置呢还是内存或其他原因？

进一步分析，寻找limits.conf未生效原因

经过初步分析，初步判断并非设置过小导致，16384设置并不算小，RHEL默认/etc/sysctl.conf中内核参数kernel.pid_max为32768也足够使用，那接下来需要排查如下：

1. /etc/security/limits.conf与/etc/security/limits.d是否设置过低 ？

2. 是否/etc/profile、/etc/profile.d/、/etc/bashrc、家目录下.bashrc、.bash_profile是否有相关ulimit配置脚本设置nproc设置过低 ？

3. 是否grid用户下真有超过16384 process占用导致无法su – grid ?

4. 是否有进程real user不属于grid但是effective user为grid消耗了grid所有进程数？
   

接下来我们继续一步一步排查

经过排查，/etc/security/limits.conf设置如下：

可以看到limits.