[20250127]21c library cache mutex的深入探究1.txt
[20250127]21c library cache mutex的深入探究1.txt
--//后记:应该是去年的事情,在21c下做oradebug dump library_cache,发现其library cache Bucket Mutex的地址的偏移量大多数
--//48字节,而以前11g下看到40字节,多出了8个字节,想看看存在那些变化,结果写了一个系列文章。我写完以后,我发现我自己写的
--//东西,回头再看发现自己阅读都很吃力,别人看估计更加不明白自己要表达的意思。也许自己在一些技术术语以及文字表达上不是很
--//好,重新整理再贴出来,估计还是很乱...
--//为此,把原先写的11g的帖子大概浏览一遍,简单介绍11g的情况,在11g之前oracle使用的是library cache latch,11g之后采用
--//library cache mutex,带来的优点是使用mutex的数量大大多于10g的library cache latch数量,10g下library cache latch数量与
--//CPU数量有关.选取大于cpu数量的最接近的质数,比如24个CPU的library cache latch的数量是29。而11g下等于Library cache hash
--//table bucket count的数量2^_kgl_bucket_count * 256。
SYS@book> @ hidez _kgl_bucket_count
SYS@book> @ pr
==============================
NAME : _kgl_bucket_count
DESCRIPTION : Library cache hash table bucket count (2^_kgl_bucket_count * 256)
DEFAULT_VALUE : TRUE
SESSION_VALUE : 9
SYSTEM_VALUE : 9
ISSES_MODIFIABLE : FALSE
ISSYS_MODIFIABLE : FALSE
PL/SQL procedure successfully completed.
--//缺省不修改参数_kgl_bucket_count的情况下2^9*256 = 131072.
--//在11g的测试中,只要启动数据库library cache mutex地址在sga的位置不会变动(除非共享池变化很大,下次启动会发生变化),
--//以前一直以为这些mutex占用内存集中在1个chunk里面,实际的测试占用多个chunk(不知道为什么这样设计),在sga在一个chunk里面
--//以类似数组形式里面保存了2^9 = 512个mutex地址,相当于N*256的mutex地址(N=0到511),定位使用那个mutex计算很简单。
--//注:21c与11g 稍微有点点不同。
--//可以参考以前写的:
[20220302]oracle如何定位使用library cache mutex 2.txt
[20220303]oracle如何定位使用library cache mutex 3.txt
--//实际上很简单在一个chunk里面记录了一张表或者讲一个数组,记录数量为2^_kgl_bucket_count,每个占8字节(我的OS 64位系统),相
--//当于N*256的mutex地址(N=0到511),假设知道基地址A后,如果知道bucket值.使用bucket/256 取整就可以定位 该地址B 保存在
--//A + trunc(bucket/256)*8的位置,再通过bucket%256 * 40 + B , 该位置就保存了该bucket的library cache mutex的地址。
--//注:21c下应该使用48计算,不是40。
--//关于mutex的结构占24字节,测试的结果如下:
--// 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。
--//另外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_wait_time=1,时间单位与_mutex_wait_scheme相关,_mutex_wait_scheme=2时时间单位是厘秒,而
--//_mutex_wait_scheme=0,1时,单位时毫秒。
--//_mutex_wait_scheme =2时,_mutex_wait_time>1时sleeps的时间会出现指数回退.
--//缺省_mutex_wait_scheme =2.
--//网上找了一段资料:
* _mutex_spin_count (Integer)
- This sets the number of times to spin before yielding/waiting.
* _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
_mutex_wait_scheme = 1 & _mutex_wait_time = t – Always SLEEP for t milli-seconds
_mutex_wait_scheme = 2 & _mutex_wait_time = t – EXP BACKOFF with maximum sleep (default)
--//具体细节看后面的相关测试。
--//另外oracle越来越走向闭源,在21c下x$ksmmem仅仅能查询一小部分内存地址信息,oradebug poke也无法执行,修改内存信息。
--//如果上帝关闭了一扇门,必他会为你打开一扇窗。可惜那扇窗oracle现在也要关上,给分析带来一点点困难。
--//不写太长,另外写具体的分析过程。
--//后记:应该是去年的事情,在21c下做oradebug dump library_cache,发现其library cache Bucket Mutex的地址的偏移量大多数
--//48字节,而以前11g下看到40字节,多出了8个字节,想看看存在那些变化,结果写了一个系列文章。我写完以后,我发现我自己写的
--//东西,回头再看发现自己阅读都很吃力,别人看估计更加不明白自己要表达的意思。也许自己在一些技术术语以及文字表达上不是很
--//好,重新整理再贴出来,估计还是很乱...
--//为此,把原先写的11g的帖子大概浏览一遍,简单介绍11g的情况,在11g之前oracle使用的是library cache latch,11g之后采用
--//library cache mutex,带来的优点是使用mutex的数量大大多于10g的library cache latch数量,10g下library cache latch数量与
--//CPU数量有关.选取大于cpu数量的最接近的质数,比如24个CPU的library cache latch的数量是29。而11g下等于Library cache hash
--//table bucket count的数量2^_kgl_bucket_count * 256。
SYS@book> @ hidez _kgl_bucket_count
SYS@book> @ pr
==============================
NAME : _kgl_bucket_count
DESCRIPTION : Library cache hash table bucket count (2^_kgl_bucket_count * 256)
DEFAULT_VALUE : TRUE
SESSION_VALUE : 9
SYSTEM_VALUE : 9
ISSES_MODIFIABLE : FALSE
ISSYS_MODIFIABLE : FALSE
PL/SQL procedure successfully completed.
--//缺省不修改参数_kgl_bucket_count的情况下2^9*256 = 131072.
--//在11g的测试中,只要启动数据库library cache mutex地址在sga的位置不会变动(除非共享池变化很大,下次启动会发生变化),
--//以前一直以为这些mutex占用内存集中在1个chunk里面,实际的测试占用多个chunk(不知道为什么这样设计),在sga在一个chunk里面
--//以类似数组形式里面保存了2^9 = 512个mutex地址,相当于N*256的mutex地址(N=0到511),定位使用那个mutex计算很简单。
--//注:21c与11g 稍微有点点不同。
--//可以参考以前写的:
[20220302]oracle如何定位使用library cache mutex 2.txt
[20220303]oracle如何定位使用library cache mutex 3.txt
--//实际上很简单在一个chunk里面记录了一张表或者讲一个数组,记录数量为2^_kgl_bucket_count,每个占8字节(我的OS 64位系统),相
--//当于N*256的mutex地址(N=0到511),假设知道基地址A后,如果知道bucket值.使用bucket/256 取整就可以定位 该地址B 保存在
--//A + trunc(bucket/256)*8的位置,再通过bucket%256 * 40 + B , 该位置就保存了该bucket的library cache mutex的地址。
--//注:21c下应该使用48计算,不是40。
--//关于mutex的结构占24字节,测试的结果如下:
--// 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。
--//另外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_wait_time=1,时间单位与_mutex_wait_scheme相关,_mutex_wait_scheme=2时时间单位是厘秒,而
--//_mutex_wait_scheme=0,1时,单位时毫秒。
--//_mutex_wait_scheme =2时,_mutex_wait_time>1时sleeps的时间会出现指数回退.
--//缺省_mutex_wait_scheme =2.
--//网上找了一段资料:
* _mutex_spin_count (Integer)
- This sets the number of times to spin before yielding/waiting.
* _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
_mutex_wait_scheme = 1 & _mutex_wait_time = t – Always SLEEP for t milli-seconds
_mutex_wait_scheme = 2 & _mutex_wait_time = t – EXP BACKOFF with maximum sleep (default)
--//具体细节看后面的相关测试。
--//另外oracle越来越走向闭源,在21c下x$ksmmem仅仅能查询一小部分内存地址信息,oradebug poke也无法执行,修改内存信息。
--//如果上帝关闭了一扇门,必他会为你打开一扇窗。可惜那扇窗oracle现在也要关上,给分析带来一点点困难。
--//不写太长,另外写具体的分析过程。
【推荐】编程新体验,更懂你的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