[20250206]21c library cache mutex的小结.txt
[20250206]21c library cache mutex的小结.txt
--//这几天一直在做21c library cache mutex相关测试,测试非常乱,实际上整个测试就是一个在摸索探究的过程,中间遇到许多自己
--//不知道的知识以及"奇怪"现象。
1.关于21c library cache mutex在sga的分配以及分布问题。
--//1.无法在使用x$ksmmem查询全部sga信息。
--//2.大部分的library cache mutex address相差48字节,比11g多了8字节,实际上只要在一个chunk里面,偏移都是48字节,除非不在
--//同一个chunk里面。
--//3.可以确定每个chunk保存256个library cache mutex的地址,chunk大小12304.这个与以前11g完成不同。
--//4.11g"数组"所在的chunk与bucket的地址在同一个chunk里面,现在单独分开了。
--//5.每个chunk开头都是00003011 00B38F00 17ADF8D0 00000000。
--//6.关于mutex的结构,我的测试的结果如下:
--// 0- 7 字节是muext的值。
--// 8-11 字节是mutex gets的数量。
--//12-15 字节是mutex sleep的数量。
--//16-19 字节是Bucket桶号。
--//20-23 字节是转储看到的6.
--//mutex地址前面16字节(0x10)2个8字节分别记录的是对象句柄地址的尾首指针,如果仅仅存在1个对象,两者相等。如果存在多个对象会
--//形成1个双向链表。如果仅仅存在0个对象,两者等于mutex的地址-0x10。
--//7.做library cache的转储,mutex的值第1值包含dump会话的sid,第4个值总是6,第2,3个值对应gets,sleeps的数量。
2.相关^_mutext参数:
SYS@book> @ hidez ^_mutex
NUM N_HEX NAME DESCRIPTION DEFAULT_VALUE SESSION_VALUE SYSTEM_VALUE ISSES ISSYS_MOD
---- ----- ------------------ ----------------- ------------- ------------- ------------ ----- ---------
3553 DE1 _mutex_wait_time Mutex wait time TRUE 1 1 FALSE IMMEDIATE
3554 DE2 _mutex_spin_count Mutex spin count TRUE 255 255 FALSE IMMEDIATE
3555 DE3 _mutex_wait_scheme Mutex wait scheme TRUE 2 2 FALSE IMMEDIATE
--//缺省设置。
--//网上找了一段资料:
* _mutex_spin_count (Integer)
- This sets the number of times to spin before yielding/waiting.
--//感觉_mutex_spin_count计数,增加会增加cpu使用,以后补充测试。
* _mutex_wait_scheme (Integer)
- In 11.2 this controls which wait scheme to use. It can be set to one of the three wait schemes described above thus:
--//基本总结如下:
_mutex_wait_scheme = 0 – Always YIELD (开始99sched_yield,1次select)
_mutex_wait_scheme = 1 & _mutex_wait_time = t – Always SLEEP for t milli-seconds (开始1次sched_yield,N次select)
_mutex_wait_scheme = 2 & _mutex_wait_time = t – EXP BACKOFF with maximum sleep (开始2次sched_yield,N次semtimedop)
--//调用getrusage的时间间隔是2秒,如此循环。除非设置_mutex_wait_time>=200。
--//关于_mutex_wait_time,缺省_mutex_wait_time=1:
--//_mutex_wait_scheme=0的情况下,无论_mutex_wait_time等于任何值,select的时间都是1毫秒,此模式消耗CPU资源最大。
--//在这种情况下单次的sleeps次数大于0xffff时存在溢出情况,估计其他模式也一样,只不过该模式容易出现。
--//_mutex_wait_scheme=0的情况下,当_mutex_wait_time=1时 select的时间是1毫秒。
--//_mutex_wait_scheme=1的情况下,当_mutex_wait_time=t时 select的时间是t毫秒。
--//_mutex_wait_scheme=0,1的情况下,当_mutex_wait_time的时间单位是毫秒.
--//_mutex_wait_scheme=2的情况下,当_mutex_wait_time=1时 semtimedop的时间是10毫秒。
--//_mutex_wait_scheme=2的情况下,当_mutex_wait_time>1时,才会出现EXP BACKOFF with maximum sleep,semtimedop的时间单位是
--//10毫秒,呈现指数增长,最大到_mutex_wait_time。
--//采用semtimedop模式,如果在此过程中其他进程释放该mutex,应该会发信号semctl,唤醒它。
--//_mutex_wait_scheme=2的情况下,_mutex_wait_time的时间单位是厘秒.
--//从消耗CPU资源比较:
--//_mutex_wait_scheme=0最大,_mutex_wait_scheme=1次之,_mutex_wait_scheme=2最小。
3.测试中遇到的gets数量变化问题:
--//tpt 的hash.sql脚本访问v$sql视图,导致gets增加,似乎其他一些底层的视图也会出现类似情况,定位有一些困难。
--//不知道测试选择bucket=0有关。
--//另外_mutex_wait_scheme=0模式,我以前的测试出现如下情况:
$ egrep "getrusage" mutex1029a.txt | head -20
15:30:54.019793 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 356432}, ru_stime={0, 26706}, ...}) = 0 <0.000018>
15:30:55.372638 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 440314}, ru_stime={0, 116028}, ...}) = 0 <0.000006>
15:30:57.307361 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 612397}, ru_stime={0, 240797}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~
15:30:57.374756 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 618929}, ru_stime={0, 245780}, ...}) = 0 <0.000006>
15:30:59.375259 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 786978}, ru_stime={0, 379507}, ...}) = 0 <0.000006>
15:31:00.439520 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 873682}, ru_stime={0, 428788}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~~
15:31:01.375677 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 946820}, ru_stime={0, 503563}, ...}) = 0 <0.000006>
15:31:03.376486 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 123685}, ru_stime={0, 640779}, ...}) = 0 <0.000008>
15:31:03.555178 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 141702}, ru_stime={0, 649892}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~~~
15:31:05.376807 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 288829}, ru_stime={0, 777355}, ...}) = 0 <0.000012>
15:31:07.378469 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 376224}, ru_stime={0, 850931}, ...}) = 0 <0.000008>
15:31:07.806124 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 410396}, ru_stime={0, 874978}, ...}) = 0 <0.000007>
~~~~~~~~~~~~~~~
15:31:09.378904 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 558816}, ru_stime={0, 961663}, ...}) = 0 <0.000006>
15:31:10.834735 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 689696}, ru_stime={1, 51871}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~~~
15:31:11.379381 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 731215}, ru_stime={1, 94707}, ...}) = 0 <0.000006>
15:31:13.379894 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 882803}, ru_stime={1, 198944}, ...}) = 0 <0.000005>
15:31:14.422316 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 969757}, ru_stime={1, 252984}, ...}) = 0 <0.000007>
~~~~~~~~~~~~~~
15:31:15.386934 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={2, 25910}, ru_stime={1, 295576}, ...}) = 0 <0.000008>
15:31:17.387530 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={2, 188196}, ru_stime={1, 406460}, ...}) = 0 <0.000006>
15:31:17.966472 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={2, 238434}, ru_stime={1, 445609}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~~~~
--//调用getrusage不再是2秒间隔,视乎中间参杂了间隔2,3秒的情况出现,看下划线。
--//当时没有仔细分析,这次测试验证与resmgr:cpu quantum有关,关闭resmgr cpu quantum该问题不再出现。
--//alter system set "_resource_manager_always_off"=true scope=spfile;
--//这几天一直在做21c library cache mutex相关测试,测试非常乱,实际上整个测试就是一个在摸索探究的过程,中间遇到许多自己
--//不知道的知识以及"奇怪"现象。
1.关于21c library cache mutex在sga的分配以及分布问题。
--//1.无法在使用x$ksmmem查询全部sga信息。
--//2.大部分的library cache mutex address相差48字节,比11g多了8字节,实际上只要在一个chunk里面,偏移都是48字节,除非不在
--//同一个chunk里面。
--//3.可以确定每个chunk保存256个library cache mutex的地址,chunk大小12304.这个与以前11g完成不同。
--//4.11g"数组"所在的chunk与bucket的地址在同一个chunk里面,现在单独分开了。
--//5.每个chunk开头都是00003011 00B38F00 17ADF8D0 00000000。
--//6.关于mutex的结构,我的测试的结果如下:
--// 0- 7 字节是muext的值。
--// 8-11 字节是mutex gets的数量。
--//12-15 字节是mutex sleep的数量。
--//16-19 字节是Bucket桶号。
--//20-23 字节是转储看到的6.
--//mutex地址前面16字节(0x10)2个8字节分别记录的是对象句柄地址的尾首指针,如果仅仅存在1个对象,两者相等。如果存在多个对象会
--//形成1个双向链表。如果仅仅存在0个对象,两者等于mutex的地址-0x10。
--//7.做library cache的转储,mutex的值第1值包含dump会话的sid,第4个值总是6,第2,3个值对应gets,sleeps的数量。
2.相关^_mutext参数:
SYS@book> @ hidez ^_mutex
NUM N_HEX NAME DESCRIPTION DEFAULT_VALUE SESSION_VALUE SYSTEM_VALUE ISSES ISSYS_MOD
---- ----- ------------------ ----------------- ------------- ------------- ------------ ----- ---------
3553 DE1 _mutex_wait_time Mutex wait time TRUE 1 1 FALSE IMMEDIATE
3554 DE2 _mutex_spin_count Mutex spin count TRUE 255 255 FALSE IMMEDIATE
3555 DE3 _mutex_wait_scheme Mutex wait scheme TRUE 2 2 FALSE IMMEDIATE
--//缺省设置。
--//网上找了一段资料:
* _mutex_spin_count (Integer)
- This sets the number of times to spin before yielding/waiting.
--//感觉_mutex_spin_count计数,增加会增加cpu使用,以后补充测试。
* _mutex_wait_scheme (Integer)
- In 11.2 this controls which wait scheme to use. It can be set to one of the three wait schemes described above thus:
--//基本总结如下:
_mutex_wait_scheme = 0 – Always YIELD (开始99sched_yield,1次select)
_mutex_wait_scheme = 1 & _mutex_wait_time = t – Always SLEEP for t milli-seconds (开始1次sched_yield,N次select)
_mutex_wait_scheme = 2 & _mutex_wait_time = t – EXP BACKOFF with maximum sleep (开始2次sched_yield,N次semtimedop)
--//调用getrusage的时间间隔是2秒,如此循环。除非设置_mutex_wait_time>=200。
--//关于_mutex_wait_time,缺省_mutex_wait_time=1:
--//_mutex_wait_scheme=0的情况下,无论_mutex_wait_time等于任何值,select的时间都是1毫秒,此模式消耗CPU资源最大。
--//在这种情况下单次的sleeps次数大于0xffff时存在溢出情况,估计其他模式也一样,只不过该模式容易出现。
--//_mutex_wait_scheme=0的情况下,当_mutex_wait_time=1时 select的时间是1毫秒。
--//_mutex_wait_scheme=1的情况下,当_mutex_wait_time=t时 select的时间是t毫秒。
--//_mutex_wait_scheme=0,1的情况下,当_mutex_wait_time的时间单位是毫秒.
--//_mutex_wait_scheme=2的情况下,当_mutex_wait_time=1时 semtimedop的时间是10毫秒。
--//_mutex_wait_scheme=2的情况下,当_mutex_wait_time>1时,才会出现EXP BACKOFF with maximum sleep,semtimedop的时间单位是
--//10毫秒,呈现指数增长,最大到_mutex_wait_time。
--//采用semtimedop模式,如果在此过程中其他进程释放该mutex,应该会发信号semctl,唤醒它。
--//_mutex_wait_scheme=2的情况下,_mutex_wait_time的时间单位是厘秒.
--//从消耗CPU资源比较:
--//_mutex_wait_scheme=0最大,_mutex_wait_scheme=1次之,_mutex_wait_scheme=2最小。
3.测试中遇到的gets数量变化问题:
--//tpt 的hash.sql脚本访问v$sql视图,导致gets增加,似乎其他一些底层的视图也会出现类似情况,定位有一些困难。
--//不知道测试选择bucket=0有关。
--//另外_mutex_wait_scheme=0模式,我以前的测试出现如下情况:
$ egrep "getrusage" mutex1029a.txt | head -20
15:30:54.019793 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 356432}, ru_stime={0, 26706}, ...}) = 0 <0.000018>
15:30:55.372638 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 440314}, ru_stime={0, 116028}, ...}) = 0 <0.000006>
15:30:57.307361 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 612397}, ru_stime={0, 240797}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~
15:30:57.374756 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 618929}, ru_stime={0, 245780}, ...}) = 0 <0.000006>
15:30:59.375259 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 786978}, ru_stime={0, 379507}, ...}) = 0 <0.000006>
15:31:00.439520 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 873682}, ru_stime={0, 428788}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~~
15:31:01.375677 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 946820}, ru_stime={0, 503563}, ...}) = 0 <0.000006>
15:31:03.376486 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 123685}, ru_stime={0, 640779}, ...}) = 0 <0.000008>
15:31:03.555178 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 141702}, ru_stime={0, 649892}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~~~
15:31:05.376807 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 288829}, ru_stime={0, 777355}, ...}) = 0 <0.000012>
15:31:07.378469 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 376224}, ru_stime={0, 850931}, ...}) = 0 <0.000008>
15:31:07.806124 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 410396}, ru_stime={0, 874978}, ...}) = 0 <0.000007>
~~~~~~~~~~~~~~~
15:31:09.378904 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 558816}, ru_stime={0, 961663}, ...}) = 0 <0.000006>
15:31:10.834735 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 689696}, ru_stime={1, 51871}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~~~
15:31:11.379381 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 731215}, ru_stime={1, 94707}, ...}) = 0 <0.000006>
15:31:13.379894 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 882803}, ru_stime={1, 198944}, ...}) = 0 <0.000005>
15:31:14.422316 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={1, 969757}, ru_stime={1, 252984}, ...}) = 0 <0.000007>
~~~~~~~~~~~~~~
15:31:15.386934 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={2, 25910}, ru_stime={1, 295576}, ...}) = 0 <0.000008>
15:31:17.387530 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={2, 188196}, ru_stime={1, 406460}, ...}) = 0 <0.000006>
15:31:17.966472 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={2, 238434}, ru_stime={1, 445609}, ...}) = 0 <0.000006>
~~~~~~~~~~~~~~~~
--//调用getrusage不再是2秒间隔,视乎中间参杂了间隔2,3秒的情况出现,看下划线。
--//当时没有仔细分析,这次测试验证与resmgr:cpu quantum有关,关闭resmgr cpu quantum该问题不再出现。
--//alter system set "_resource_manager_always_off"=true scope=spfile;
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
2024-02-19 [20240219]建立完善sql_idx.sh脚本.txt
2019-02-19 [20190219]那个更快(11g).txt