[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现在也要关上，给分析带来一点点困难。 --//不写太长，另外写具体的分析过程。