OS内核参数（Sem）在高负载的Oracle数据库中如何设置
时间:2025-11-04 21:35:30 出处:应用开发阅读（143）
本文转载自微信公众号「数据和云」，内核作者李汝宁。参数转载本文请联系数据和云公众号。负载
概述
文章主要围绕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.2.接下来我详细描述一下自己遇到的两个真实案例。云南idc服务商
案例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:00Process J000 died,see its trace file
2019-12-03T01:26:04.312263+08:00kkjcre1p:unable to spawn jobq slave process
1.2.3.4.5.6. 节点2 复制WARNING: inbound connection timed out (ORA-3136)2019-12-03T01:28:25.950983+08:00Process J002 died,see its trace file
2019-12-03T01:28:25.951070+08:00kkjcre1p:unable to spawn jobq slave process
1.2.3.4.5.此处，只贴出关键报错信息，后面持续性的报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 10241.在之后的单节点承载测试中，连接数成功突破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 = 1024max semaphores per array = 250max semaphores system wide = 146000max ops per semop call = 250semaphore max value = 32767# ipcs -su
------ Semaphore Status --------used arrays = 272 --在日常13000+ process的状态下，使用了272个信号量组。allocated semaphores = 38133 --已经使用的信号量（总146000），明显是足够的。1.2.3.4.5.6.7.8.9.10.11.12.13.于是在调整完成信号量参数后，我们进行了单节点停机演练，验证新的信号量参数(kerner.sem)能否满足单节点运行需求。
节点1： 复制2021-12-1709:30:01 PM 31 13519 24.78 26.05 28.03 009:40:01 PM 45 13474 28.73 28.47 28.57 009:50:01 PM 54 13918 27.31 28.56 28.60 010:00:01 PM 65 13466 28.11 27.69 28.04 110:10:01 PM 54 13670 29.18 27.58 28.15 010:20:01 PM 57 13198 35.87 32.77 30.33 010:30:01 PM 52 13173 32.03 30.19 30.24 010:40:01 PM 57 13122 32.24 30.37 30.15 010:50:01 PM 49 13150 28.20 28.64 29.48 011:00:01 PM 45 13150 24.03 25.16 27.52 211:10:01 PM 9 3076 27.37 105.85 70.37 011:20:01 PM 7 2850 0.39 14.61 37.11 011:30:01 PM 8 2857 0.38 2.34 19.66 011:40:01 PM 9 2845 0.48 0.67 10.48 011:50:01 PM 8 2850 0.25 0.32 5.62 0Average: 60 13295 33.67 35.52 36.43 02021-12-1812:00:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15blocked
12:10:01 AM 9 5389 14.70 7.11 4.50 112:20:01 AM 23 6713 8.95 9.64 7.22 012:30:01 AM 18 7035 11.01 10.36 9.00 012:40:01 AM 12 7490 3.14 5.94 7.54 012:50:01 AM 14 6733 2.27 2.56 4.90 101:00:01 AM 29 5022 4.42 2.97 3.96 101:10:01 AM 29 4962 2.92 3.63 4.29 001:20:01 AM 27 8605 2.54 3.05 3.80 001:30:01 AM 32 10291 6.28 4.43 4.16 101:40:01 AM 60 12306 26.22 19.36 11.30 301:50:01 AM 52 12847 36.66 32.88 22.02 002:00:01 AM 70 20817 70.41 61.77 40.55 102:10:01 AM 88 20033 58.30 64.47 53.57 002:20:02 AM 99 20078 62.88 58.93 55.96 002:30:01 AM 99 19124 59.93 57.16 56.03 002:40:01 AM 93 19150 70.50 68.64 63.37 102:50:01 AM 79 18866 45.37 51.29 57.55 003:00:01 AM 48 12739 36.84 39.46 48.23 103:10:01 AM 25 9589 2.92 11.12 29.84 003:20:01 AM 17 9371 2.18 3.97 17.10 003:30:02 AM 24 10371 2.20 3.33 10.66 003:40:01 AM 25 10124 2.44 2.90 7.06 103:50:01 AM 25 10255 2.81 3.13 5.28 004:00:01 AM 24 7977 2.93 3.73 4.71 104:10:01 AM 28 10241 12.13 6.87 5.42 004:20:01 AM 35 11449 19.92 17.72 12.37 004:30:01 AM 47 13315 27.29 27.07 19.95 004:40:01 AM 55 12858 24.53 27.80 24.23 01.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49. 节点2： 复制2021-12-1709:10:01 PM 72 11665 21.82 22.33 21.91 109:20:01 PM 35 11687 21.65 22.62 22.43 109:30:01 PM 34 11668 21.61 23.01 22.53 109:40:01 PM 46 11950 23.53 21.81 21.90 009:50:02 PM 32 11871 21.52 21.52 21.78 110:00:01 PM 42 11834 23.25 21.89 21.65 010:10:01 PM 50 11654 24.37 23.45 22.56 010:20:01 PM 46 11610 24.64 25.12 24.15 010:30:01 PM 38 11395 19.02 21.87 23.21 010:40:01 PM 29 11378 20.44 21.14 22.35 010:50:01 PM 35 11376 26.31 22.89 22.38 311:00:01 PM 48 11402 23.64 23.36 22.72 211:10:01 PM 113 21039 93.61 61.46 38.21 311:20:01 PM 81 20908 56.74 66.72 52.95 311:30:01 PM 84 21024 66.29 64.21 58.26 011:40:01 PM 104 19471 68.32 67.28 62.95 011:50:02 PM 104 19650 65.64 63.52 62.71 0Average: 40 11946 23.99 24.14 23.95 02021-12-1812:00:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15blocked
12:10:02 AM 723 20713 371.66 168.59 108.50 1012:20:01 AM 153 20946 477.30 469.98 312.59 312:30:02 AM 544 20626 465.03 470.04 388.70 312:40:01 AM 490 15461 423.75 440.90 413.35 112:50:01 AM 411 16521 343.58 379.77 399.10 001:00:01 AM 376 11176 483.01 440.15 417.56 11.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.我们先后重启节点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(复制链接至浏览器浏览)
