[20210819]kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI 2.txt
[20210819]kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI 2.txt
--//2019年的測試。我當時在設定核心引數kernel.sem = 24 332800 100 128時，不知道會使用25個Semaphore Arrays。
--//前幾天與別人聊天，我記得當時測試時一頭霧水，不知道為什麼，不浪費時間直接放棄?最近仔細看當時做的筆記，似乎明白問題在
--//那裡？
--//連結:http://blog.itpub.net/267265/viewspace-2664807/ =>[20191119]探究ipcs命令輸出2.txt
--//kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI,很明顯解析如下：
kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI
where
SEMMSL max semaphores per array
SEMMNS max semaphores system wide ,SEMMSL*SEMMNI=2600*128 = 332800
SEMOPM max ops per semop call， SEMOPM=SEMMSL?
SEMMNI max number of arrays
--//SEM 表示 Semaphore.
--//今天我大概看一遍,大概猜測出如何建立Semaphore Arrays.透過例子說明:
1.環境:
--//為了反覆測試,我建立一個例項,沒有資料檔案.
$ cat /tmp/test.ora
test.__db_cache_size=1258291200
test.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
test.__shared_pool_size=1048576000
*.db_name='test'
*.processes=200
*.sga_target=2500M
*.undo_management='auto'
--//設定環境變數:
$ export ORACLE_SID=test
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 24 332800 100 128
# sysctl -p
2.測試1:
$ export ORACLE_SID=test
SYS@test> startup force nomount pfile='/tmp/@.ora';
ORACLE instance started.
Total System Global Area 2622255104 bytes
Fixed Size 2256112 bytes
Variable Size 1124074256 bytes
Database Buffers 1476395008 bytes
Redo Buffers 19529728 bytes
$ ipcs -s
------ Semaphore Arrays --------
key semid owner perms nsems
0xc13ea218 26050560 oracle 640 12
0xc13ea219 26083329 oracle 640 12
0xc13ea21a 26116098 oracle 640 12
0xc13ea21b 26148867 oracle 640 12
0xc13ea21c 26181636 oracle 640 12
0xc13ea21d 26214405 oracle 640 12
0xc13ea21e 26247174 oracle 640 12
0xc13ea21f 26279943 oracle 640 12
0xc13ea220 26312712 oracle 640 12
0xc13ea221 26345481 oracle 640 12
0xc13ea222 26378250 oracle 640 12
0xc13ea223 26411019 oracle 640 12
0xc13ea224 26443788 oracle 640 12
0xc13ea225 26476557 oracle 640 12
0xc13ea226 26509326 oracle 640 12
0xc13ea227 26542095 oracle 640 12
0xc13ea228 26574864 oracle 640 12
0xc13ea229 26607633 oracle 640 12
0xc13ea22a 26640402 oracle 640 12
0xc13ea22b 26673171 oracle 640 12
0xc13ea22c 26705940 oracle 640 12
0xc13ea22d 26738709 oracle 640 12
0xc13ea22e 26771478 oracle 640 12
0xc13ea22f 26804247 oracle 640 12
0xc13ea230 26837016 oracle 640 12
$ ipcs -s | grep "^0x" |wc -l
25
$ ipcs -s -l
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 24
max semaphores system wide = 332800
max ops per semop call = 100
semaphore max value = 32767
--//最後semaphore max value 引數不知道在哪裡可以修改.
$ ipcs -us
------ Semaphore Status --------
used arrays = 25
allocated semaphores = 300
--//12*25 = 300
--//我當時的演算法:
--//首先看SEMMSL是否大於等於processes+4.如果大於等於僅僅建立1個Semaphore Arrays.
--//如果SEMMSL小於processes+4,使用processes+4除以2的冪指數,也就是2,4,8,16等等.
--//比如當前processes+4=200+4=204,然後分別除以2,4,8,16.... 結果小於SEMMSL,就再建立相應數量Semaphore Arrays.
--//我當時猜測的Semaphore Arrays的nsems演算法是對的，但是分配Semaphore Arrays的數量相差很大。
--//當前semmsl＝24
--//204/2 = 102.大於SEMMSL,不行.
--//204/4 = 51,大於SEMMSL,不行。
--//204/8 = 25.5,大於SEMMSL，不行
--//204/16 = 12.75,,注這裡取整12，對應Semaphore Arrays的nsems=12.
--//我當時的猜測應該建立Semaphore Arrays=16,考慮一些餘量加上1個就是17.而實際建立的是25。
--//我當時怎麼也沒有想明白這個問題，實際上我忽略一個細節，說明如下。
$ ipcs -p
------ Shared Memory Creator/Last-op --------
shmid owner cpid lpid
35913730 oracle 53565 53607
35946499 oracle 53565 53607
35979268 oracle 53565 53607
36012037 oracle 53565 53607
36044806 oracle 53565 53607
36077575 oracle 53565 53607
------ Message Queues PIDs --------
msqid owner lspid lrpid
--//cpid=53565表示Shared Memory Creator的程式號,53607表示最後operation Shared Memory的程式號.
--//另外該程式號建立完成後已經不存在，不知道為什麼ipcs -s -i <shmid>查詢不釋放。
--//有點奇怪的是為什麼使用6個共享記憶體段.視乎與我定義vm.nr_hugepages,vm.nr_overcommit_hugepages引數大小有關另外寫一篇
--//blog.
$ ipcs -m -u
------ Shared Memory Status --------
segments allocated 8
pages allocated 643681
pages resident 79730
pages swapped 0
Swap performance: 0 attempts 0 successes
--//注:root使用者使用2個。oracle使用者使用6個。
$ ipcs -s | awk '/0x/ {print $2}' | xargs -IQ ipcs -s -i Q | awk '$5>0 {print $0}'
--//$5>0 主要原因避免輸出太長。
otime = Wed Sep 1 10:20:46 2021
ctime = Wed Sep 1 10:20:46 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
7 0 1 0 53570
9 0 1 0 53576
otime = Wed Sep 1 10:20:43 2021
ctime = Wed Sep 1 10:20:43 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
5 0 1 0 53584
10 0 1 0 53594
otime = Wed Sep 1 10:20:46 2021
ctime = Wed Sep 1 10:20:46 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
5 0 1 0 53600
8 0 0 0 53605
9 0 0 0 53607
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
ctime = Wed Sep 1 10:20:41 2021
semnum value ncount zcount pid
0 1 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
otime = Wed Sep 1 10:20:43 2021
ctime = Wed Sep 1 10:20:43 2021
semnum value ncount zcount pid
0 0 0 0 53565
1 2559 0 0 53565
2 19574 0 0 53565
3 1 0 0 53565
11 0 0 0 53565
--//實際上每個Semaphore Arrays已經消耗了4個。注意看pid列=53565.佔用semnum=0,1,2,3.對應Shared Memory Creator的程式號。
--//最後一個Semaphore Arrays非常特殊,在semnum=11,pid=53565,也是已經消耗5個,我估計表示結束。
--//我不知道為什麼佔用的Shared Memory Creator的程式號不會釋放.
--//計算Semaphore Arrays的數量演算法應該是 ceil(processes/(nsems-4)) ,結果使用ceil取整。
--//ceil(200/(12-4)) = 25
--//另外你可以看出實際分配的最大程式數量是processes-1 = 200-1=199.計算如下:
--// 24*(12-4)+12-5 = 199
--//簡單解析 前面24個Semaphore Arrays ,僅僅12－4=8個可用,最後的Semaphore Arrays要使用12-5(從0開始記數).
--//繼續可以做一個簡單驗證，修改核心引數如下:
3.測試2:
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 11 332800 100 128
--//注:kernel.sem = 12 332800 100 128,結果與kernel.sem = 24 332800 100 128一樣.
# sysctl -p
--//204/2 = 102.大於SEMMSL,不行.
--//204/4 = 51,大於SEMMSL,不行。
--//204/8 = 25.5,大於SEMMSL，不行
--//204/16 = 12.75,大於SEMMSL，不行
--//204/32 = 6.375,注這裡floor取整6，小於等於SEMMSL。對應Semaphore Arrays的nsems=6.
--//200/(6-4) = 100,應該建立Semaphore Arrays的數量是100。
SYS@test> startup force nomount pfile='/tmp/@.ora';
ORACLE instance started.
Total System Global Area 2622255104 bytes
Fixed Size 2256112 bytes
Variable Size 1124074256 bytes
Database Buffers 1476395008 bytes
Redo Buffers 19529728 bytes
$ ipcs -s | head
------ Semaphore Arrays --------
key semid owner perms nsems
0xc13ea218 27885568 oracle 640 6
0xc13ea219 27918337 oracle 640 6
0xc13ea21a 27951106 oracle 640 6
0xc13ea21b 27983875 oracle 640 6
0xc13ea21c 28016644 oracle 640 6
0xc13ea21d 28049413 oracle 640 6
0xc13ea21e 28082182 oracle 640 6
--//nsens=6
$ ipcs -s | tail
0xc13ea273 30867547 oracle 640 6
0xc13ea274 30900316 oracle 640 6
0xc13ea275 30933085 oracle 640 6
0xc13ea276 30965854 oracle 640 6
0xc13ea277 30998623 oracle 640 6
0xc13ea278 31031392 oracle 640 6
0xc13ea279 31064161 oracle 640 6
0xc13ea27a 31096930 oracle 640 6
0xc13ea27b 31129699 oracle 640 6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--//nsens=6
$ ipcs -s | grep "^0x" |wc -l
100
--//與我估計一致.
$ ipcs -p
------ Shared Memory Creator/Last-op --------
shmid owner cpid lpid
36372482 oracle 53938 53981
36405251 oracle 53938 53981
36438020 oracle 53938 53981
36470789 oracle 53938 53981
36503558 oracle 53938 53981
36536327 oracle 53938 53981
------ Message Queues PIDs --------
msqid owner lspid lrpid
--//檢視最後1個semid=31129699.
$ ipcs -s -i 31129699 | awk '$5>0 {print $0}'
otime = Wed Sep 1 10:41:22 2021
ctime = Wed Sep 1 10:41:22 2021
semnum value ncount zcount pid
0 0 0 0 53938
1 2559 0 0 53938
2 19574 0 0 53938
3 1 0 0 53938
5 0 0 0 53938
--//最後一個Semaphore Arrays 已經佔用5個.
--//99*(6-4)+6-5 = 199
4.繼續測試:
--//如果修改如下,SEMMNI=99.
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 11 332800 100 99
ORACLE instance shut down.
SYS@test> startup force nomount pfile='/tmp/@.ora';
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpcreates
--//SEMMNI=99,表示max number of arrays,在這樣的情況下需要100,可以發現無法啟動資料庫，設定100可以透過.
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 11 332800 100 100
SYS@test> startup force nomount pfile='/tmp/@.ora';
ORACLE instance started.
Total System Global Area 2622255104 bytes
Fixed Size 2256112 bytes
Variable Size 1124074256 bytes
Database Buffers 1476395008 bytes
Redo Buffers 19529728 bytes
5.繼續,測試SEMMNS=max semaphores system wide ,SEMMSL*SEMMNI.
--//kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 204 203 100 128
SYS@test> startup force nomount pfile='/tmp/@.ora';
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpsemid2
ORA-27303: additional information: maxsems = 204, verify_semcnt = 0
--//因為processes=200,processes+4=204，僅僅建立1個Semaphore Arrays,而SEMMNS=203,無法容納.
--//這樣也可以看出為什麼建議設定SEMMNS=SEMMSL*SEMMNI,這樣保證足夠.
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 204 204 100 128
# sysctl -p
SYS@test> startup force nomount pfile='/tmp/@.ora';
ORACLE instance started.
Total System Global Area 2622255104 bytes
Fixed Size 2256112 bytes
Variable Size 1124074256 bytes
Database Buffers 1476395008 bytes
Redo Buffers 19529728 bytes
--//ok,可以啟動資料庫.
$ ipcs -sl
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 204
max semaphores system wide = 204
max ops per semop call = 100
semaphore max value = 32767
$ ipcs -s
------ Semaphore Arrays --------
key semid owner perms nsems
0xc13ea218 38502400 oracle 640 204
--//nsems=204,僅僅需要1個Semaphore Arrays.
$ ipcs -us
------ Semaphore Status --------
used arrays = 1
allocated semaphores = 204
$ ipcs -p
------ Shared Memory Creator/Last-op --------
shmid owner cpid lpid
38666242 oracle 54298 54340
38699011 oracle 54298 54340
38731780 oracle 54298 54340
38764549 oracle 54298 54340
38797318 oracle 54298 54340
38830087 oracle 54298 54340
------ Message Queues PIDs --------
msqid owner lspid lrpid
$ ipcs -s | awk '/0x/ {print $2}' | xargs -IQ ipcs -s -i Q | awk '$5>0 {print $0}'
otime = Wed Sep 1 11:02:55 2021
ctime = Wed Sep 1 11:02:55 2021
semnum value ncount zcount pid
0 0 0 0 54298
1 2559 0 0 54298
2 19574 0 0 54298
3 1 0 0 54298
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7 0 1 0 54303
9 0 1 0 54309
13 0 1 0 54317
18 0 1 0 54327
21 0 1 0 54333
24 0 0 0 54338
25 0 0 0 54340
203 0 0 0 54298
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--//204-5=199.有一點點奇怪是並非每個程式都使用Semaphore.僅僅7個程式使用Semaphore。
$ ipcs -s | awk '/0x/ {print $2}' | xargs -IQ ipcs -s -i Q | awk '$5>0 {print $5}'| grep -v 54298 | grep 54 | paste -sd, | xargs -IQ ps -fp Q
UID PID PPID C STIME TTY TIME CMD
oracle 54303 1 0 11:02 ? 00:00:00 ora_psp0_test
oracle 54309 1 0 11:02 ? 00:00:00 ora_gen0_test
oracle 54317 1 0 11:02 ? 00:00:00 ora_mman_test
oracle 54327 1 0 11:02 ? 00:00:00 ora_ckpt_test
oracle 54333 1 0 11:02 ? 00:00:00 ora_mmon_test
$ ps -ef| grep ora[_]
oracle 54301 1 0 11:02 ? 00:00:00 ora_pmon_test
oracle 54303 1 0 11:02 ? 00:00:00 ora_psp0_test
oracle 54305 1 1 11:02 ? 00:00:10 ora_vktm_test
oracle 54309 1 0 11:02 ? 00:00:00 ora_gen0_test
oracle 54311 1 0 11:02 ? 00:00:00 ora_diag_test
oracle 54313 1 0 11:02 ? 00:00:00 ora_dbrm_test
oracle 54315 1 0 11:02 ? 00:00:00 ora_dia0_test
oracle 54317 1 0 11:02 ? 00:00:00 ora_mman_test
oracle 54319 1 0 11:02 ? 00:00:00 ora_dbw0_test
oracle 54321 1 0 11:02 ? 00:00:00 ora_dbw1_test
oracle 54323 1 0 11:02 ? 00:00:00 ora_dbw2_test
oracle 54325 1 0 11:02 ? 00:00:00 ora_lgwr_test
oracle 54327 1 0 11:02 ? 00:00:00 ora_ckpt_test
oracle 54329 1 0 11:02 ? 00:00:00 ora_smon_test
oracle 54331 1 0 11:02 ? 00:00:00 ora_reco_test
oracle 54333 1 0 11:02 ? 00:00:00 ora_mmon_test
oracle 54335 1 0 11:02 ? 00:00:00 ora_mmnl_test
$ ps -ef| grep ora[_] |wc
17 136 1054
6.繼續,測試SEMOPM=max ops per semop call， SEMOPM=SEMMSL?
--//kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI
--//http://blog.itpub.net/26736162/viewspace-2147273/
③ 100表示SEMOPM，設定每次系統呼叫可以同時執行的最大訊號燈操作的數量。由於一個訊號燈組最多擁有SEMMSL個訊號燈，因此有推薦
將SEMOPM設定為SEMMSL的值。Oracle驗證的10.2和11.1的SEMOPM的配置為100。
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 204 204 0 1
--//注:SEMOPM=0
# sysctl -p
SYS@test> startup force nomount pfile='/tmp/@.ora';
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:try = 0 failed with status: 0
ORA-27301: OS failure message: Error 0
ORA-27302: failure occurred at: sskgpfind5
ORA-27303: additional information: sems_per_set = 204
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 204 204 1 1
SYS@test> startup force nomount pfile='/tmp/@.ora';
ORACLE instance started.
Total System Global Area 2622255104 bytes
Fixed Size 2256112 bytes
Variable Size 1124074256 bytes
Database Buffers 1476395008 bytes
Redo Buffers 19529728 bytes
--//不理解這個概念,設定SEMOPM=1也可以啟動.
$ seq 150 | xargs -IQ -P150 bash -c "sqlplus -s -l / as sysdba <<< 'select sysdate from dual;^Jhost sleep 5'"
--//執行完成沒有問題.
--//既然oracle推薦設定SEMOPM=SEMMSL,我建議按照推薦設定.
7.總結:
--//Semaphore Arrays的nsems按照如下計算
--//processes+4 小於等於SEMMSL ,nsem=processes+4.
--//(processes+4)/N,N=2的冪(2,4,8,16,32....).,再使用floor取整,小於等於SEMMSL，nsems = floor((processes+4)/N ).
--//Semaphore Arrays數量的演算法應該是 ceil(processes/(nsems-4)) ,結果向下取整。
--//另外我看了連結http://blog.itpub.net/267265/viewspace-2664807/=>[20191119]探究ipcs命令輸出2.txt
--//zergduan的評論 2020-05-19 19:23:54
你的測試是正確的，但是也是有侷限的，你看到4個訊號量被保留，不做分配，是因為你在AMD/Intel x86架構的伺服器上測試；這個架構
保留值就是4，其它架構保留值不一樣，但是一般不會超過10，所以網上經常說第一個值設定為processes+10; 其實這是為了讓一個例項
的只使用一個訊號量集，這對於processes很小的例項是可以的，但是對於processes很大的例項，就不應該這樣設定了。
--//也就是linux 是+4,其它os可能是processes+10.
--//另外引出另外的問題使用1個Semaphore Arrays還是多個.我看了我們生產系統rac設定:
# grep "^kernel.s[he]" /etc/sysctl.conf
kernel.shmmax = 229982982348
kernel.shmall = 56148189
kernel.shmmni = 4096
kernel.sem = 1024 60000 1024 256
--//SEMMNS也並沒有按照1024*256 = 262144,而是設定60000.我個人建議如果processes不大,儘量在1個Semaphore Arrays為好.
--//好像多個Semaphore Arrays也看不出什麼效能問題,對於os這些概念基本不熟悉,那位給出一些好的建議.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2789967/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20210819]給檔案內容編行號.txt
- linux系統關於kernel.sem調優Linux
- [20191011]拆分rowid 2.txt
- [20180625]oradebug peek 2.txt
- [20231027]Index ITL Limit 2.txtIndexMIT
- [20210828]如何實現2.txt
- [20220322]探究oracle sequence 2.txtOracle
- [20210223]bbed itl ktbitflg 2.txt
- [20181113]Logical Standby建立2.txt
- [20190102]塊內重整2.txt
- [20231025]跟蹤rename操作2.txt
- [20220531]inactive session等待事件2.txtSession事件
- [20210507]dump library_cache 2.txt
- [20191209]降序索引疑問2.txt索引
- [20190826]update結果集2.txt
- [20190720]sqlplus 與輸出& 2.txtSQL
- [20190419]shared latch spin count 2.txt
- [20180705]關於hash join 2.txt
- [20231115]建立enable novalidate約束2.txt
- [20230427]bbed sum apply問題2.txtAPP
- [20230108]ORA-00600 and Session Disconnected 2.txtSession
- [20210924]awk奇怪的輸出2.txt
- [20210508]分析library cache轉儲 2.txt
- [20191125]oracel SQL parsing function qcplgte 2.txtSQLFunction
- [20191126]探究等待事件的本源2.txt事件
- [20200305]netstat state=ESTABLISHED and timer=probe 2.txt
- [20191119]探究ipcs命令輸出2.txt
- [20191128]oracle Audit檔案管理2.txtOracle
- [20200316]dmesg與時間戳2.txt時間戳
- [20200718]注意sql hint寫法2.txtSQL
- [20210107]快速進入目錄2.txt
- [20210413]CBC latch再討論2.txt
- [20210317]如何知道索引塊地址2.txt索引
- [20190116]詭異的問題2.txt
- [20190823]關於CPU成本計算2.txt
- [20190913]完善vim的bccacl外掛2.txt
- [20191113]oracle共享連線模式埠2.txtOracle模式
- [20211221]提示precompute_subquery補充2.txt