os内核参数（SEM）在高负载的ORACLE数据库中如何设置

原创 Jack.Li 云和恩墨交付战队 2021-12-30

3888

概述

文章主要围绕OS内核参数kernel.sem来讲解，在各类DB（ORA、PG、MYSQL等）安装手册中都会引导大家设置sem这个参数，很多初中级DBA大多是照本宣科并不明白其中含义，更不清楚如何设置才是正确的，在真实的高负载生产环境中未正确设置这个参数真的会产生“生产事故”。写本文的目的是引导DBA同仁避免和我一样踩到信号量的坑里去。

参数含义

kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI
SEMMSL: Maximum number of semaphores per set（每个信号量组中信号量最大数量）
SEMMNS: Maximum number of semaphores system-wide（整个Linux系统中所有信号量的最大数量，建议是第1和第4个数字的乘积）
SEMOPM: Maximum number of semaphore operations per system call（每次semop系统调用可以同时执行的最大信号量操作的数量semopm。由于一个信号量组最多拥有SEMMSL个信号量，推荐将SEMOPM设置为SEMMSL的值）
SEMMNI: Maximum number of semaphore sets for the entire Linux system（设置系统中信号量组的最大数量）

查看当前的信号量方法

# cat /proc/sys/kernel/sem
250     32000   32      128  (这几个值分别是:SEMMSL, SEMMNS, SEMOPM, and SEMMNI)
复制

接下来我详细描述一下自己遇到的两个真实案例。

案例1：信号量设置过小引发的链接故障

背景：这是一套客户的核心RAC 2节点数据库，日常会话连接数稳定在12000左右。2019年12月3日凌晨因数据库session连接激增，单节点会话增加到164xx的时候就无法继续增加连接，而我们的process限制为30000。

贴出当时环境的会话连接信息

查看当时alert日志：

节点1:

Process m000 died, see its trace file
Process m000 died, see its trace file
2019-12-03T01:26:04.312179+08:00
Process J000 died, see its trace file
2019-12-03T01:26:04.312263+08:00
kkjcre1p: unable to spawn jobq slave process 

复制

节点2

WARNING: inbound connection timed out (ORA-3136)
2019-12-03T01:28:25.950983+08:00
Process J002 died, see its trace file
2019-12-03T01:28:25.951070+08:00
kkjcre1p: unable to spawn jobq slave process 

复制

此处，只贴出关键报错信息，后面持续性的报kkjcre1p: unable to spawn jobq slave process 。
因此我们怀疑可能是os方面的资源限制。
查看两个节点的ulimit ,并没有明显较小资源限制。

查看故障期间session连接情况

查看监听日志每分钟的连接信息（从01:26日志报错时间点连接激增）

查看sar信息里面的进程队列信息（进程数基本稳定，os资源没问题），所以判定是超过某个参数设置。

因为这个库的连接数很大，从os层面排查发现参数kernel.sem 设置较小，怀疑是这个参数导致系统资源不足，因为oracle服务进程需要使用信号量通讯，1个server进程最少一个信号量。
服务器当前设置为：12000 1536000 100 128

解决：

在这里我们借鉴了恩墨安装手册的最佳实践（可能是某ACE总结的），内容如下：

我们的DB两个节点process总量为24000左右，所以协商决定修改参数如下：

kernel.sem = 32000 32768000 32000 1024
复制

在之后的单节点承载测试中，连接数成功突破16000的限制，但是调整如此大的信号量又给我们埋下了另外一个雷。

案例2：信号量设置过大导致 SYS CPU 100% 资源耗尽

背景：还是这套核心RAC 2节点数据库，在硬解析比较严重，并发量大的情况下发生了 SYS CPU 100% ，几乎所有的CPU 核都达到了95%+的一个状态。

之后经过原厂+第三方专家的多轮会诊，得出结论：1、信号量太大了。2、MMAN（Memory Manager Process，内存管理进程）出现了问题，db buffer 和 shared pool 争用比较严重。

本次文章主要是说明信号量问题，所以MMAN和硬解析SQL问题就不详细描述了，总之这是一个高负载情况下的并发症。

原厂给出的解决方案：将信号量调小（kernel.sem = 250 146000 250 1024）

信号量调整这么小，尤其是SEMMSL 250 （网络上大部分都建议我们此值要设置为 process+10），但是经过这次验证显然是一个错误的结论。

使用如下方法查看当前信号量设置和使用量：

#ipcs -ls
------ Semaphore Limits --------
max number of arrays = 1024
max semaphores per array = 250
max semaphores system wide = 146000
max ops per semop call = 250
semaphore max value = 32767

# ipcs -su

------ Semaphore Status --------
used arrays = 272    --在日常13000+ process的状态下，使用了272个信号量组。
allocated semaphores = 38133   --已经使用的信号量（总146000），明显是足够的。
复制

于是在调整完成信号量参数后，我们进行了单节点停机演练，验证新的信号量参数（kerner.sem）能否满足单节点运行需求。

节点1：

2021-12-17
09:30:01 PM        31     13519     24.78     26.05     28.03         0
09:40:01 PM        45     13474     28.73     28.47     28.57         0
09:50:01 PM        54     13918     27.31     28.56     28.60         0
10:00:01 PM        65     13466     28.11     27.69     28.04         1
10:10:01 PM        54     13670     29.18     27.58     28.15         0
10:20:01 PM        57     13198     35.87     32.77     30.33         0
10:30:01 PM        52     13173     32.03     30.19     30.24         0
10:40:01 PM        57     13122     32.24     30.37     30.15         0
10:50:01 PM        49     13150     28.20     28.64     29.48         0
11:00:01 PM        45     13150     24.03     25.16     27.52         2
11:10:01 PM         9      3076     27.37    105.85     70.37         0
11:20:01 PM         7      2850      0.39     14.61     37.11         0
11:30:01 PM         8      2857      0.38      2.34     19.66         0
11:40:01 PM         9      2845      0.48      0.67     10.48         0
11:50:01 PM         8      2850      0.25      0.32      5.62         0
Average:           60     13295     33.67     35.52     36.43         0

2021-12-18

12:00:01 AM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
12:10:01 AM         9      5389     14.70      7.11      4.50         1
12:20:01 AM        23      6713      8.95      9.64      7.22         0
12:30:01 AM        18      7035     11.01     10.36      9.00         0
12:40:01 AM        12      7490      3.14      5.94      7.54         0
12:50:01 AM        14      6733      2.27      2.56      4.90         1
01:00:01 AM        29      5022      4.42      2.97      3.96         1
01:10:01 AM        29      4962      2.92      3.63      4.29         0
01:20:01 AM        27      8605      2.54      3.05      3.80         0
01:30:01 AM        32     10291      6.28      4.43      4.16         1
01:40:01 AM        60     12306     26.22     19.36     11.30         3
01:50:01 AM        52     12847     36.66     32.88     22.02         0
02:00:01 AM        70     20817     70.41     61.77     40.55         1
02:10:01 AM        88     20033     58.30     64.47     53.57         0
02:20:02 AM        99     20078     62.88     58.93     55.96         0
02:30:01 AM        99     19124     59.93     57.16     56.03         0
02:40:01 AM        93     19150     70.50     68.64     63.37         1
02:50:01 AM        79     18866     45.37     51.29     57.55         0
03:00:01 AM        48     12739     36.84     39.46     48.23         1
03:10:01 AM        25      9589      2.92     11.12     29.84         0
03:20:01 AM        17      9371      2.18      3.97     17.10         0
03:30:02 AM        24     10371      2.20      3.33     10.66         0
03:40:01 AM        25     10124      2.44      2.90      7.06         1
03:50:01 AM        25     10255      2.81      3.13      5.28         0
04:00:01 AM        24      7977      2.93      3.73      4.71         1
04:10:01 AM        28     10241     12.13      6.87      5.42         0
04:20:01 AM        35     11449     19.92     17.72     12.37         0
04:30:01 AM        47     13315     27.29     27.07     19.95         0
04:40:01 AM        55     12858     24.53     27.80     24.23         0
复制

节点2：

2021-12-17
09:10:01 PM        72     11665     21.82     22.33     21.91         1
09:20:01 PM        35     11687     21.65     22.62     22.43         1
09:30:01 PM        34     11668     21.61     23.01     22.53         1
09:40:01 PM        46     11950     23.53     21.81     21.90         0
09:50:02 PM        32     11871     21.52     21.52     21.78         1
10:00:01 PM        42     11834     23.25     21.89     21.65         0
10:10:01 PM        50     11654     24.37     23.45     22.56         0
10:20:01 PM        46     11610     24.64     25.12     24.15         0
10:30:01 PM        38     11395     19.02     21.87     23.21         0
10:40:01 PM        29     11378     20.44     21.14     22.35         0
10:50:01 PM        35     11376     26.31     22.89     22.38         3
11:00:01 PM        48     11402     23.64     23.36     22.72         2
11:10:01 PM       113     21039     93.61     61.46     38.21         3
11:20:01 PM        81     20908     56.74     66.72     52.95         3
11:30:01 PM        84     21024     66.29     64.21     58.26         0
11:40:01 PM       104     19471     68.32     67.28     62.95         0
11:50:02 PM       104     19650     65.64     63.52     62.71         0
Average:           40     11946     23.99     24.14     23.95         0

2021-12-18
12:00:01 AM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
12:10:02 AM       723     20713    371.66    168.59    108.50        10
12:20:01 AM       153     20946    477.30    469.98    312.59         3
12:30:02 AM       544     20626    465.03    470.04    388.70         3
12:40:01 AM       490     15461    423.75    440.90    413.35         1
12:50:01 AM       411     16521    343.58    379.77    399.10         0
01:00:01 AM       376     11176    483.01    440.15    417.56         1
复制

我们先后重启节点1、节点2，之后通过监控数据库session的链接和os层面的进程数量（最高21000+），都能够正常承接所有的业务会话链接，并没有发生连接数不足的情况。

总结：

kernel.sem 参数中真正限制数据库process链接数量的并非SEMMSL(每个信号集中的最大信号量数目),而是SEMMNS（系统范围内的最大信号量总数目）和SEMMNI（系统范围内的最大信号集总数目）。

SEMMSL与SEMOPM 通常设置一样的值即可，250个足以。

附录：

ORACLE官方文档对于kernel.sem设置建议：
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/cwlin/tuning-semaphore-parameters.html#GUID-467E41B6-2B11-426E-9447-A4D8BF8E26C6

最后修改时间：2021-12-30 15:41:56

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

11 0

1年前

👍

1年前

Jack.Li

3年前

补充：根据 OS 厂商的解释，skgpwwait 调用了操作系统内核提供的 API 函数 (semtimedop), 该函数主要用于用户态进（线）间通信实现等待和释放信号量，防止多进（线）程并发同时访问一个共享资源（业务资源如共享内存、共享文件、数据库表等），出现资源争抢触发异常。目前来看 CPU 时间主要消耗在信号量等待上（semtimedop 内部使用 spin_lock 实现），导致 CPU sys%偏高。

3年前

red_hope

3年前

很多时候，数据库启停出现问题，也是信号量不释放导致。

3年前