[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这些概念基本不熟悉,那位给出一些好的建议.
[20210819]kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI 2.txt
来源:这里教程网
时间:2026-03-03 16:54:23
作者:
编辑推荐:
- [20210819]kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI 2.txt03-03
- [20210828]如何实现2.txt03-03
- ORACLE编译失效对象小结03-03
- [20210902]为什么会使用多个共享内存段.txt03-03
- Oracle:RBO 简介03-03
- 【SQL】关于Oracle12c SQL调整中一些变化03-03
- kill session ORA-0003103-03
- 农夫山泉挺赚钱03-03
下一篇:
相关推荐
-
雷神推出 MIX PRO II 迷你主机:基于 Ultra 200H,玻璃上盖 + ARGB 灯效
2 月 9 日消息,雷神 (THUNDEROBOT) 现已宣布推出基于英
-
制造商 Musnap 推出彩色墨水屏电纸书 Ocean C:支持手写笔、第三方安卓应用
2 月 10 日消息,制造商 Musnap 现已在海外推出一款 Oce
热文推荐
- kill session ORA-00031
kill session ORA-00031
26-03-03 - 农夫山泉挺赚钱
农夫山泉挺赚钱
26-03-03 - 中通财报:“增收不增利”怪圈难破
中通财报:“增收不增利”怪圈难破
26-03-03 - 【SQL】Oracle批量提交和频繁提交区别测试
【SQL】Oracle批量提交和频繁提交区别测试
26-03-03 - 唯品会的“成年烦心事”
唯品会的“成年烦心事”
26-03-03 - 21C在RHEL单节点图形化安装
21C在RHEL单节点图形化安装
26-03-03 - 高增长趋缓,金山云拉开了新战局帷幕
高增长趋缓,金山云拉开了新战局帷幕
26-03-03 - 云集的社交电商转弯
云集的社交电商转弯
26-03-03 - 【ORACLE21C】Oracle21c 只读目录说明
【ORACLE21C】Oracle21c 只读目录说明
26-03-03 - Oracle RAC NFS挂载文件系统
Oracle RAC NFS挂载文件系统
26-03-03
