[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博客 ” ，链接：https://blog.itpub.net/267265/viewspace-2789967/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- [20261008]验证Shared Memory Segments key以及Semaphore Arrays Key(11g).txt
- [20261008]gdb引入结构体是否可行.txt
- [20261008]bpftrace定义结构体例子.txt
- [20261007]关于oracle sskgph2函数.txt
- [20261007]oracle Semaphore Arrays Key值的冲突.txt
- [20261004]oracle sskgph2函数等价c以及python脚本.txt
- [20261004]bpftrace查看oracle函数调用堆栈问题.txt
- [20261002]验证sskgphpjw函数参与运算的字符串是否存在规律.txt
- [20261002]oracle Semaphore Arrays Key值的计算2.txt
- [20261001]oracle Semaphore Arrays Key值的计算.txt
