首页 » ORACLE [C]系列, 系统相关 » Troubleshooting ORA-27300 ‘fork failed with status: 11’ on SLES12 (SUSE /Linux 7)

Troubleshooting ORA-27300 ‘fork failed with status: 11’ on SLES12 (SUSE /Linux 7)

近日新装的一套ORACLE 12.2  RAC on SLES 12在使用srvctl start database 有时失败, alert log 中出现ORA-27300、ORA-27301、ORA-27302错误, 从错误不难看出是OS资源资源限制, 这可能以后使用SUSE的用户会是个常见问题, 因为这是SLES 12的默认参数限制,而且ORACLE的安装文档和最佳实践中也未提到该参数(至少当前没有找到)。

alert log file

2018-11-19 09:29:03.940000 +08:00
Process P01E died, see its trace file
Process startup failed, error stack:
Errors in file /oracle/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_psp0_32198.trc:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn3
2018-11-19 09:29:04.940000 +08:00
Process P01F died, see its trace file
Process startup failed, error stack:
Errors in file /oracle/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_psp0_32198.trc:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn3

Note:
从当前的错误fork failed with status: 11可以大概猜测是最大进程数限制导致fork()进程时失败, 另外一处是psp0进程fork() Pnnn的进程。

PSP trace file

oracle@kdanbob01:/home/oracle> vi /oracle/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_psp0_32198.trc
Trace file /oracle/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_psp0_32198.trc
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
Build label:    RDBMS_12.2.0.1.0_LINUX.X64_170125
ORACLE_HOME:    /oracle/app/oracle/product/12.2.0/db_1
System name:    Linux
Node name:      kdanbob01
Release:        4.4.21-69-default
Version:        #1 SMP Tue Oct 25 10:58:20 UTC 2016 (9464f67)
Machine:        x86_64
Instance name: anbob1
Redo thread mounted by this instance: 0 
Oracle process number: 4
Unix process pid: 32198, image: oracle@kdanbob01 (PSP0)


*** 2018-11-19T09:15:26.133868+08:00
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn3
OS - DIAGNOSTICS
----------------
loadavg : 42.40 27.56 11.09
Memory (Avail / Total) = 176425.47M / 515676.77M
Swap (Avail / Total) = 32768.00M /  32768.00M
Max user processes limits(s / h) =  65536 / 65536

oracle@kdanbob01:/home/oracle> ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 2062629
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

what’s psp Process?

The first process that will be started when we start instance is PSP process. This is called PROCESS SPAWNER. This process is introduced in 10g and is responsible for creating and managing other oracle backgroung processes.
Pnnn进程都知道是并行进程,查看并行相关的参数

SQL> show parameter parallel

PARAMETER_NAME                                               TYPE        VALUE
------------------------------------------------------------ ----------- ---------------------------------
containers_parallel_degree                                   integer     65535
fast_start_parallel_rollback                                 string      LOW
parallel_adaptive_multi_user                                 boolean     FALSE
parallel_degree_limit                                        string      CPU
parallel_degree_policy                                       string      MANUAL
parallel_execution_message_size                              integer     16384
parallel_force_local                                         boolean     TRUE
parallel_instance_group                                      string
parallel_max_servers                                         integer     60
parallel_min_percent                                         integer     0
parallel_min_servers                                         integer     60
parallel_min_time_threshold                                  string      AUTO
parallel_servers_target                                      integer     60
parallel_threads_per_cpu                                     integer     2
recovery_parallelism                                         integer     8
SQL> @pd containers_parallel_degree
Show all parameters and session values from x$ksppi/x$ksppcv...

      INDX I_HEX NAME                            VALUE                          DESCRIPTION
---------- ----- ------------------------------ ------------------------------ ---------------------------------------
      4749  128D containers_parallel_degree     65535                          Parallel degree for a CONTAINERS() query

Tip:
开始我以为是12cR2 新特性导致的该问题,containers_parallel_degree 当使用containers()查询或打开PDB时并行度的上限值, 当前环境是个非CDB模式的数据库, 不过我个人还是建议在12.2 中使用多租户,哪怕是1PDBs, 在19c NO-CDB都是NO supperted。 如果只是因为是不想用CDB而多SCHEMA模式,我认为CDB优点更多: 言归正传回到刚才的问题,trace文件中提示系统max user process是65536, oracle用户限制是16384, 这些参数配置可以通过/etc/security/limits.conf修改,通过ulimit -a命令验证, 手动ps了一下oracle和grid用户进程根本没有那么(少于400), 在MOS中找到一篇符合这个问题的NOTE ,  SLES 12: Database Startup Error with ORA-27300 ORA-27301 ORA-27303 While Starting using Srvctl (文档 ID 2340986.1)

From SLES12 onwards, systemd is used instead of initd and the OHASD server is only allowed to open a maximum of 512 tasks.

SYSTEMD从SLES12后用Systemd 取代 SysV的Init, 有SYSTEMD init程序管理 OHASD服务,SYSTEMD也就是PID=1的那个程序,有它来统一管理启动,也是为了标准化系统启动和管理,可以并行启动等优点加快了启动速度,但是SYSTEMD是一个很受争议的东西,因为很多过去系统命令不得不放弃重新学习,有些人反对为了那一点启动上的提升而引入了这个一个体积庞大的强耦合程序,违背了”keep simple, keep stupid”的Unix 哲学,知乎上有篇吐槽Systemd的贴子,但是在新版LINUX上是主推Systemd。同样LINUX 7以后同样默认也是使用Systemd init启动程序。

在LINUX 6及以前的版本查’max user processes’ 使用 ‘ulimit -a’ ,但是以LINUX7(SLES12) 后引入了Systemd, Systemd可以管理所有系统资源,不同的资源统称为Unit,  以后就可能需要查DefaultTasksMax (default value is 512).

DefaultTasksMax   ==>systemd limited maximum number of tasks that may be created in the unit.This setting also effect maxpid value on OS.

 

$  >  systemctl status ohasd
● ohasd.service – LSB: Start and Stop Oracle High Availability Service
Loaded: loaded (/etc/init.d/ohasd; bad; vendor preset: disabled)
Active: active (exited) since Mon 2018-11-19 11:36:59 CST; 23h ago
Docs: man:systemd-sysv-generator(8)
Process: 12385 ExecStart=/etc/init.d/ohasd start (code=exited, status=0/SUCCESS)
Tasks: 726 (limit: 65535) — 这个值在修改前应该是512

解决办法

Configure the value of DefaultTasksMax to 65535 in the file /etc/systemd/system.conf or or set the TasksMax value properly for the ohasd systemd service.

这里我们使用的解决方法是修改/etc/systemd/system.conf  把DefaultTasksMax改成 了65535,当然也可以直接改成’infinity’ 无限。修改参数需要重启操作系统生效。

建议在SLSE 12或以后的版本,或LINUX 7等以后的版本时,先了解一下系统变化,对于过去版本中资源限制如:nproc  、nofile、memlock 在以后OS版本中有DefaultTasksMax、DefaultLimitNOFILE、DefaultLimitMEMLOCK替代, 可能Oracle 在以后的安装文档或最佳实践中会增加该内容。

打赏

, , ,

目前这篇文章还没有评论(Rss)

我要评论