[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;