建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「數(shù)據(jù)和云」，作者李汝寧。轉(zhuǎn)載本文請(qǐng)聯(lián)系數(shù)據(jù)和云公眾號(hào)。
創(chuàng)新互聯(lián)建站主營托克遜網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,成都APP應(yīng)用開發(fā),托克遜h5微信小程序開發(fā)搭建,托克遜網(wǎng)站營銷推廣歡迎托克遜等地區(qū)企業(yè)咨詢
概述
文章主要圍繞OS內(nèi)核參數(shù)kernel.sem來講解。在各類DB(ORA、PG、MYSQL等)安裝手冊(cè)中都會(huì)引導(dǎo)大家設(shè)置sem這個(gè)參數(shù)，很多初中級(jí)DBA大多是照本宣科并不明白其中含義，更不清楚如何設(shè)置才是正確的，在真實(shí)的高負(fù)載生產(chǎn)環(huán)境中未正確設(shè)置這個(gè)參數(shù)真的會(huì)產(chǎn)生“生產(chǎn)事故”。寫本文的目的是引導(dǎo)DBA同仁避免和我一樣踩到信號(hào)量的坑里去。
01參數(shù)含義
kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI
- SEMMSL: Maximum number of semaphores per set(每個(gè)信號(hào)量組中信號(hào)量最大數(shù)量)
- SEMMNS: Maximum number of semaphores system-wide(整個(gè)Linux系統(tǒng)中所有信號(hào)量的最大數(shù)量，建議是第1和第4個(gè)數(shù)字的乘積)
- SEMOPM: Maximum number of semaphore operations per system call(每次semop系統(tǒng)調(diào)用可以同時(shí)執(zhí)行的最大信號(hào)量操作的數(shù)量semopm。由于一個(gè)信號(hào)量組最多擁有SEMMSL個(gè)信號(hào)量，推薦將SEMOPM設(shè)置為SEMMSL的值)
- SEMMNI: Maximum number of semaphore sets for the entire Linux system(設(shè)置系統(tǒng)中信號(hào)量組的最大數(shù)量)
02查看當(dāng)前的信號(hào)量方法
# cat /proc/sys/kernel/sem
250 32000 32 128 (這幾個(gè)值分別是:SEMMSL, SEMMNS, SEMOPM, and SEMMNI)
接下來我詳細(xì)描述一下自己遇到的兩個(gè)真實(shí)案例。
案例1：信號(hào)量設(shè)置過小引發(fā)的鏈接故障
背景：這是一套客戶的核心RAC 2節(jié)點(diǎn)數(shù)據(jù)庫，日常會(huì)話連接數(shù)穩(wěn)定在12000左右。2019年12月3日凌晨因數(shù)據(jù)庫session連接激增，單節(jié)點(diǎn)會(huì)話增加到164xx的時(shí)候就無法繼續(xù)增加連接，而我們的process限制為30000。
貼出當(dāng)時(shí)環(huán)境的會(huì)話連接信息：
查看當(dāng)時(shí)alert日志：
節(jié)點(diǎn)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
節(jié)點(diǎn)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
此處，只貼出關(guān)鍵報(bào)錯(cuò)信息，后面持續(xù)性的報(bào)kkjcre1p: unable to spawn jobq slave process 。因此我們懷疑可能是OS方面的資源限制。
查看兩個(gè)節(jié)點(diǎn)的ulimit ,并沒有明顯較小資源限制。
查看故障期間session連接情況：
查看監(jiān)聽日志每分鐘的連接信息(從01:26日志報(bào)錯(cuò)時(shí)間點(diǎn)連接激增)：
查看sar信息里面的進(jìn)程隊(duì)列信息(進(jìn)程數(shù)基本穩(wěn)定，OS資源沒問題)，所以判定是超過某個(gè)參數(shù)設(shè)置。
因?yàn)檫@個(gè)庫的連接數(shù)很大，從OS層面排查發(fā)現(xiàn)參數(shù)kernel.sem 設(shè)置較小，懷疑是這個(gè)參數(shù)導(dǎo)致系統(tǒng)資源不足，因?yàn)镺racle服務(wù)進(jìn)程需要使用信號(hào)量通訊，1個(gè)server進(jìn)程最少一個(gè)信號(hào)量。
服務(wù)器當(dāng)前設(shè)置為：12000 1536000 100 128
解決：
在這里我們借鑒了恩墨安裝手冊(cè)的最佳實(shí)踐(可能是某ACE總結(jié)的)，內(nèi)容如下：
我們的DB兩個(gè)節(jié)點(diǎn)process總量為24000左右，所以協(xié)商決定修改參數(shù)如下：
kernel.sem = 32000 32768000 32000 1024
在之后的單節(jié)點(diǎn)承載測(cè)試中，連接數(shù)成功突破16000的限制，但是調(diào)整如此大的信號(hào)量又給我們埋下了另外一個(gè)雷。
案例2：信號(hào)量設(shè)置過大導(dǎo)致 SYS CPU 100% 資源耗盡
背景：還是這套核心RAC 2節(jié)點(diǎn)數(shù)據(jù)庫，在硬解析比較嚴(yán)重，并發(fā)量大的情況下發(fā)生了 SYS CPU 100% ，幾乎所有的CPU 核都達(dá)到了95%+的一個(gè)狀態(tài)。
之后經(jīng)過原廠+第三方專家的多輪會(huì)診，得出結(jié)論：
- 信號(hào)量太大了。
- MMAN(Memory Manager Process，內(nèi)存管理進(jìn)程)出現(xiàn)了問題，db buffer 和 shared pool 爭(zhēng)用比較嚴(yán)重。
本文主要是說明信號(hào)量問題，所以MMAN和硬解析SQL問題就不詳細(xì)描述了，總之這是一個(gè)高負(fù)載情況下的并發(fā)癥。
原廠給出的解決方案：將信號(hào)量調(diào)小(kernel.sem = 250 146000 250 1024)
信號(hào)量調(diào)整這么小，尤其是SEMMSL 250 (網(wǎng)絡(luò)上大部分都建議我們此值要設(shè)置為 process+10)，但是經(jīng)過這次驗(yàn)證顯然是一個(gè)錯(cuò)誤的結(jié)論。
使用如下方法查看當(dāng)前信號(hào)量設(shè)置和使用量：
#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的狀態(tài)下，使用了272個(gè)信號(hào)量組。
allocated semaphores = 38133 --已經(jīng)使用的信號(hào)量（總146000），明顯是足夠的。
于是在調(diào)整完成信號(hào)量參數(shù)后，我們進(jìn)行了單節(jié)點(diǎn)停機(jī)演練，驗(yàn)證新的信號(hào)量參數(shù)(kerner.sem)能否滿足單節(jié)點(diǎn)運(yùn)行需求。
節(jié)點(diǎn)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
節(jié)點(diǎn)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
我們先后重啟節(jié)點(diǎn)1、節(jié)點(diǎn)2，之后通過監(jiān)控?cái)?shù)據(jù)庫session的鏈接和OS層面的進(jìn)程數(shù)量(最高21000+)，都能夠正常承接所有的業(yè)務(wù)會(huì)話鏈接，并沒有發(fā)生連接數(shù)不足的情況。
總結(jié)：
kernel.sem 參數(shù)中真正限制數(shù)據(jù)庫process鏈接數(shù)量的并非SEMMSL(每個(gè)信號(hào)集中的最大信號(hào)量數(shù)目),而是SEMMNS(系統(tǒng)范圍內(nèi)的最大信號(hào)量總數(shù)目)和SEMMNI(系統(tǒng)范圍內(nèi)的最大信號(hào)集總數(shù)目)。
SEMMSL與SEMOPM 通常設(shè)置一樣的值即可，250個(gè)足以。
附錄
Oracle官方文檔對(duì)于kernel.sem設(shè)置建議：
??https://docs.oracle.com/en/database/oracle/oracle-database/12.2/cwlin/tuning-semaphore-parameters.html#GUID-467E41B6-2B11-426E-9447-A4D8BF8E26C6(復(fù)制鏈接至瀏覽器瀏覽)??
新聞名稱：OS內(nèi)核參數(shù)（Sem）在高負(fù)載的Oracle數(shù)據(jù)庫中如何設(shè)置
網(wǎng)頁網(wǎng)址：http://www.fisionsoft.com.cn/article/cdcsjjo.html
