本文转载自微信公众号「数据和云」，作者李汝宁。转载本文请联系数据和云公众号。
概述
文章主要围绕OS内核参数kernel.sem来讲解。在各类DB(ORA、PG、MYSQL等)安装手册中都会引导大家设置sem这个参数，很多初中级DBA大多是照本宣科并不明白其中含义，更不清楚如何设置才是正确的，在真实的高负载生产环境中未正确设置这个参数真的会产生“生产事故”。写本文的目的是引导DBA同仁避免和我一样踩到信号量的坑里去。
01参数含义
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(设置系统中信号量组的最大数量)
02查看当前的信号量方法
# 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%+的一个状态。
之后经过原厂+第三方专家的多轮会诊，得出结论：
- 信号量太大了。
- 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(复制链接至浏览器浏览)
