本文转载自微信公众号《数据与云》，作者李润宁。转载本文请联系数据和云公众号。概述文章主要针对OS内核参数kernel.sem进行讲解。在各种DB（ORA、PG、MYSQL等）安装手册中，都会引导你设置sem参数。很多初中级DBA大多是照本宣科，不理解其中的含义，更谈不上如何正确设置。未能在生产工作负载中正确设置此参数确实会造成“生产事故”。写这篇文章的目的是为了引导DBA同仁避免像我一样踏入信号量的坑。01参数含义kernel.sem=SEMMSLSEMMNSSEMOPMSEMMNISEMMSL：Maximumnumberofsemaphoresperset（每个信号量组中信号量的最大数量）SEMMNS：Maximumnumberofsemaphoressystem-wide（整个Linux系统中所有信号量的最大数量，建议是第1和第4个数的乘积）SEMOPM：Maximumnumberofsemaphoreoperationspersystemcall（每个semop系统调用可以同时执行的最大信号量操作数semopm。由于一个信号量组最多有SEMMSL信号量，建议设置SEMOPM为SEMMSL的值)SEMMNI:MaximumnumberofsemaphoresetsfortheentireLinuxsystem(设置系统中信号量组的最大数量)02查看当前信号量的方法#cat/proc/sys/kernel/sem2503200032128（这几个值分别是：SEMMSL、SEMMNS、SEMOPM、SEMMNI）接下来我将详细描述我遇到的两个真实案例。案例一：信号量设置太小导致链接失败背景：这是一个客户的核心RAC2节点数据库，日会话连接数稳定在12000左右。2019年12月3日凌晨，由于数据库会话连接激增，当单节点会话数增加到164xx时，无法继续增加连接，我们的进程限制为30000。贴出当前环境的session连接信息：查看当时的alert日志：Node1:Processm000died,SeeitstracefileProcessm000died,Seeitstracefile2019-12-03T01:26:04.312179+08:00ProcessJ000died，查看其跟踪文件2019-12-03T01:26:04.312263+08:00kkjcre1p:unabletospawnjobqslaveprocessnode2WARNING:inboundconnectiontimedout(ORA-3136)2019-12-03T01:28:25.950983+08:00Processed,J002seetracefile2019-12-03T01:28:25.951070+08:00kkjcre1p:unabletospawnjobqslaveprocess这里只贴关键错误信息，后面不断报kkjcre1p:unabletospawnjobqslaveprocess。所以我们怀疑这可能是操作系统方面的资源限制。查看两个节点的ulimits，没有明显的最小资源限制。查看故障期间的session连接状态：查看监控日志的每分钟连接信息（从01:26报错日志开始连接激增）：查看sar信息中的进程队列信息（进程数基本稳定，OS资源没有问题），判断为超出某个参数设置。因为这个库的连接数很大，所以在OS层面发现参数kernel.sem的设置很小。怀疑是这个参数导致系统资源不足，因为Oracle服务进程需要使用信号量通信，而一个服务器进程至少有一个信号量。服务器当前设置为：120001536000100128解决方法：这里参考了Enmo安装手册的最佳实践（大概是一个ACE总结的），内容如下：我们的进程总数两个节点的DB是24000左右，所以协商决定修改参数如下：kernel.sem=3200032768000320001024在后面的单节点承载测试中，连接数成功超过16000的限制，但是调整这样一个大信号量给了我们另一个信号量。雷。案例二：信号量设置过大导致SYSCPU资源耗尽100%背景：依然是核心RAC2节点数据库。SYSCPU100%发生在硬解析严重，并发量大的时候，几乎所有的CPU核心都达到了95%+的状态。经过原厂+第三方专家几轮协商，得出的结论是信号量过大。MMAN（MemoryManagerProcess，内存管理进程）出现问题，dbbuffer和sharedpool争用严重。本文主要讲解信号量问题，MMAN和硬解析SQL问题不再详述。简而言之，这是高负载条件下的并发症。原厂给出的解决方案：减小信号量(kernel.sem=2501460002501024)把信号量调整到这么小，尤其是SEMMSL250（网上大部分建议我们把这个值设置为process+10），但是经过这个验证显然是一个错误的结论。使用以下方法查看当前信号量设置和使用情况：#ipcs-ls------SemaphoreLimits--------maxnumberofarrays=1024maxsemaphoresperarray=250maxsemaphoressystemwide=146000maxopspersemopcall=250semaphoremaxvalue=32767#ipcs-su------SemaphoreStatus------usedarrays=272--在每天13000+进程的状态下，使用了272个信号量组。allocatedsemaphores=38133--已经使用的信号量（总共146000个），显然够用了。所以在调整信号量参数后，我们进行了单节点宕机演练，验证新的信号量参数（kerner.sem）能否满足单节点运行需求。节点1：2021-1709：30：01PM311351924.7826.0528.03009：40：01PM451347328.4728.4728.4728.57009：50：50：50：01PM1391801PM571319835.8732.32.33010:30:01PM521317332.24010:40:40:01PM5730.2430.1430.10.1430.1430.1430.10011:00:01PM451315024.0325.1627.52211:01PM9307.37105.8570.37011:01下午7285037.11011:01下午8285.3011:01下午8285.3011:01:01下午928450.480.6710.48011:50:01PM828500.250.325.620Average:601329533.6735.5236.4302021-12-1812:00:01AMrunq-szplist-szldavg-15ldavg-15阻止ldavg-15：01AM9538914.707.114.50112：20：01AM2367138.959.647.22012：30：01AM18703511.0110.369.00012：40：40：40：01AM1274902.564.90101：00：01AM2950224.422.973.96101：10：10：01AM2949622.923.634.29001：20：20：01AM2786052.542.543.053.803.803.80凌晨1点601230626.2219.3611.30301：50：01AM521284736.6632.8822.02002：00：01AM702081770.4161.7740.55102：10：10：10：01AM882003358.302003358.3064.4753.53.53.53.53.53.53.53.53.53.53.53.53.53.53.53.530.2：02AM999920072.8.8.88.8.8.8.8.88.88.88.88.88.88;01AM991912459.9357.1656.03002:40:01AM931915070.5068.6463.37102:50:01AM791886645.3751.2957.55003:00:01AM481273936.8439.4648.23103:10:01AM2595892.9211.1229.84003:20:01AM1793712.183.9717.10003:30:02AM24103712.203.3310.66003:40:01AM25101242.442.907.06103:50:01AM25102552.813.135.28004:00:01是2479772.932.933.734.73:10:01AM281024112.136.875.42004:01AM351144919.9217.7217.37004:01AM471331527.07:01AM551285327.Nodes2:10:01PM721166521.8222.3321.91109：20：01PM35116822.43109：01PM34116822.53109：01PM461195023.81.81.81.81.81.81.812222PM32PM321187121.5221.78.6501.6.6501.6.6501.6.6.6501.6.6.65010:10:01PM501165424.3722.56010:01PM464.15015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015015下午381139519。0221.8723.21010：40：01PM291137820.4421.1421.1422.35010：50：50：01PM351137626.3122.3122.38311：00：01：01：01：01：01PM812090856.7466.7252.95311：311：30：01PM842102466.2964.2158.26011：40：40：01PM1041947168.3268.3267.3267.2862.9562.95011：50：50：50：50：50：50：50：50：50：50：50：50：50：02PM1041965065.65.65.63.63.63.63.63.63.63.64.69.64.69.64.69.64.69.69.64.69.69.64.69in12-1812:00:01AMrunq-szplist-szldavg-1ldavg-5ldavg-15blocked12:10:02AM72320713371.66168.59108.501012:20:01AM15320946477.30469.98:312.539312.66168.59上午54420626465.03470.04388.70312：40：01AM49015461423.75440.90413.35112：50：01AM411AM41116521343.58379.77399.10001：00：00：01AM376AM37611176483.01440.15440.15417.56我们已经在RESTASEnodenodenodenodenode。而OS层面的进程数（高达21000+），可以正常承担所有的业务会话连接，不存在连接不足的情况。总结：kernel.sem参数确实限制了数据库进程的连接数。集中了最大信号量数），而是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（复制链接到浏览器）
