分享好友 站长动态首页 网站导航

OS内核参数(Sem)在高负载的Oracle数据库中如何设置

2022-03-31 09:46 · 头闻号数据库

本文转载自微信公众号「数据和云」,作者李汝宁。转载本文请联系数据和云公众号。

概述

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

01参数含义

kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI

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和硬解析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(复制链接至浏览器浏览)​​

免责声明:本平台仅供信息发布交流之途,请谨慎判断信息真伪。如遇虚假诈骗信息,请立即举报

举报
反对 0
打赏 0
更多相关文章

评论

0

收藏

点赞