[20240529]简单探究FREE LISTS列表.txt

[20240529]简单探究FREE LISTS列表.txt

--//简单探究shraed pool的FREE LISTS列表.

1.环境:
SYS@test> @ver1
PORT_STRING          VERSION    BANNER                                                                               CON_ID
-------------------- ---------- -------------------------------------------------------------------------------- ----------
IBMPC/WIN_NT64-9.1.0 12.2.0.1.0 Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0

--//关闭数据库启动到mount状态,主要方便观察,不然变化影响测试观察.
SYS@test> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

SYS@test> startup mount
ORACLE instance started.
Total System Global Area  805306368 bytes
Fixed Size                  8924064 bytes
Variable Size             297796704 bytes
Database Buffers          490733568 bytes
Redo Buffers                7852032 bytes
Database mounted.

2.做堆转储:

SYS@test> @ init
SYS@test> alter session set events 'immediate trace name heapdump level 2';
Session altered.

SYS@test> @ t
TRACEFILE
-----------------------------------------------------------------
D:\APP\ORACLE\diag\rdbms\test\test\trace\test_ora_3708.trc

--//查看相关chunk的内容:
--//看看Bucket 3的情况size=56,后面出现是RESERVED FREE LISTS:
$ sed  -n  "/^ Bucket 3 /,/^ Bucket 4 /p" test_ora_3708.trc
 Bucket 3 size=56
  Chunk      7ff0197df68 sz=       56    free      "               "
  Chunk      7ff02b8b4a8 sz=       56    free      "               "
  Chunk      7ff037a8368 sz=       56    free      "               "
 Bucket 4 size=64
 Bucket 3 size=56
 Bucket 4 size=64

--//顺便贴一个FREE LISTS的情况,仅仅启动到mount.
Total heap size    =176156736
FREE LISTS:
 Bucket 0 size=32
  Chunk      7ff0b000088 sz=        0    kghdsx
 Bucket 1 size=40
 Bucket 2 size=48
  Chunk      7ff01ffdf90 sz=       48    free      "               "
  Chunk      7ff033310c0 sz=       48    free      "               "
 Bucket 3 size=56
  Chunk      7ff0197df68 sz=       56    free      "               "
  Chunk      7ff02b8b4a8 sz=       56    free      "               "
  Chunk      7ff037a8368 sz=       56    free      "               "
 Bucket 4 size=64
  Chunk      7ff013bb058 sz=       64    free      "               "
 Bucket 5 size=72
...
 Bucket 30 size=272
  Chunk      7ff013bd300 sz=      272    free      "               "
 Bucket 31 size=280
 ...
 Bucket 254 size=65560
  Chunk      7ff00834000 sz=  3898152    free      "               "
Total free space   =  3898752
--//仅仅启动到mount,自由空间全部在最后一个bucket 254,前面仅仅存在几个free chunk,这样好做分析.

$ sed  -n  "/^ Bucket 3 /,/^ Bucket 4 /p" test_ora_3708.trc |  awk '/Chunk/{print  "oradebug peek 0x" toupper($2),32, 1 }'
oradebug peek 0x7FF0197DF68 32 1
oradebug peek 0x7FF02B8B4A8 32 1
oradebug peek 0x7FF037A8368 32 1

--//退出会话重新登陆,执行如下:
SYS@test> @ t
TRACEFILE
-----------------------------------------------------------------
D:\APP\ORACLE\diag\rdbms\test\test\trace\test_ora_7324.trc

SYS@test> oradebug setmypid
Statement processed.

SYS@test> oradebug peek 0x7FF0197DF68 32 1
[7FF0197DF68, 7FF0197DF88) = 00000039 C0B38F00 0197DF28 000007FF 0AC5DD48 00000000 02B8B4B8 000007FF
                                                                 ~~~~~~~~~~~~~~~~~ ++++++++++++++++
SYS@test> oradebug peek 0x7FF02B8B4A8 32 1
[7FF02B8B4A8, 7FF02B8B4C8) = 00000039 C0B38F00 02B7B9D0 000007FF 0197DF78 000007FF 037A8378 000007FF
                                                                 ~~~~~~~~~~~~~~~~~ ++++++++++++++++
SYS@test> oradebug peek 0x7FF037A8368 32 1
[7FF037A8368, 7FF037A8388) = 00000039 C0B38F00 03434000 000007FF 02B8B4B8 000007FF 0AC5DD48 00000000
                                                                 ~~~~~~~~~~~~~~~~~ ++++++++++++++++
--//0x39 = 57,表示chunk size+1.
--//注意看下划线以及+++相关内容,注意intel系列CPU的大小头问题.
--//前后都出现0AC5DD48 00000000.
--//02B8B4B8 000007FF 颠倒过来就是 000007FF 02B8B4B8,减去0x10就是000007FF 02B8B4A8与Chunk 7ff02b8b4a8一致.
--//0197DF78 000007FF 颠倒过来就是 000007FF 0197DF78,减去0x10就是000007FF 0197DF68与Chunk 7ff0197df68一致.
--//037A8378 000007FF 颠倒过来就是 000007FF 037A8378,减去0x10就是000007FF 037A8368与Chunk 7FF037A8368一致.
--//前面表示上一个,后面表示下一个,这样看就形成1个环.
--//这样很清晰展示free list 一个bucket桶里面的free chunk地址如何链接在一起的.

--//可以猜测存在一个单独free list区,包含地址0x0AC5DD48.
SYS@test> oradebug peek 0x0AC5DD48 32
[00AC5DD48, 00AC5DD68) = 037A8378 000007FF 0197DF78 000007FF 00000040 00000000 013BB068 000007FF
                         ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
--//大小头颠倒, 000007FF037A8378 , 000007FF0197DF78,减去0x10对应前面转储看到的尾部,头部.
--//下面确定一个bucket在free list区占用多少空间,实际上从前面的输出可以猜测占用24字节,因为00000040 00000000不可能是地址.
--//似乎表示某种长度,0x40 = 64,仅仅是猜测.
--//013BB068 000007FF 颠倒过来就是 000007FF 013BB068,减去0x10就是 000007FF 013BB058,仔细看前面跟踪的输出
 Bucket 4 size=64
  Chunk      7ff013bb058 sz=       64    free      "               "
--//正好是bucket 4的内容,可以确定一个bucket在free list区占24字节.

--//看跟踪文件下一个bucket 4,仅仅一个chunk.
 Bucket 4 size=64
  Chunk      7ff013bb058 sz=       64    free      "               "

SYS@test> oradebug peek 0x7ff013bb058 32
[7FF013BB058, 7FF013BB078) = 00000041 C0B38F00 013B7858 000007FF 0AC5DD60 00000000 0AC5DD60 00000000
                                                                 ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
--// 0x41 = 65 =chunk size+1,第4-7字节都是C0B38F00.第8-11,12-15字节内容我不知道表示怎么?无法猜测...

SYS@test> oradebug peek 0x0AC5DD60 24
[00AC5DD60, 00AC5DD78) = 013BB068 000007FF 013BB068 000007FF 00000048 00000000
--//000007FF 013BB068 - 0x10 = 0x7ff013bb058,后面的00000048 00000000猜测不出来.视乎增大1个bucket,增加8.
--//每个bucket占用 0AC5DD60-0AC5DD48 = 0x18 = 24.
--//0x48 = 72,哦似乎明白了,这个值表示这个free list bucket桶的最大chunk size是72-1=71.可以在后面单独验证.

SYS@test> @ fchaz 0x0AC5DD60
no rows selected
--//奇怪没有输出!!

--//看看这个地址0x0AC5DD60在那里:
SYS@test> oradebug ipc
IPC information written to the trace file
SYS@test> @ t
TRACEFILE
-----------------------------------------------------------------
D:\APP\ORACLE\diag\rdbms\test\test\trace\test_ora_7324.trc

*** 2024-05-30T20:44:35.830155+08:00 (CDB$ROOT(1))
Processing Oradebug command 'ipc'
Dump of Windows skgm context
areaflags            000017ff
realmflags           00001b01
maxtotalrealmsize    936d0000
VMpagesize           00001000
VMallocgranularity   00010000
minappaddress 0000000000010000
maxappaddress 000007FFFFFEFFFF
stacklimit    0000000023981000
magic                acc01ade
Handle:      0000000001260060 `sga_test'
Dump of Windows realm handle `sga_test', flags = 00000000
 Area #0 `Fixed Size' containing Subareas 0-0
  Total size 0000000000882ba0 Minimum Subarea size 00000000
   Area  Subarea                Start Addr
      0        0          000000000AB10000
                              Subarea size
                                  08925184
    [
      Base = 000000000AB10000 Prot = RW  Size =          8925184 State = COM
    ]
--//AB10000    = 179372032
--//179372032+8925184 = 188297216
--//188297216 = 0xb393000
--//0x0AC5DD60 在 0xAB10000    - 0xb393000之间.也就是free list表在fixed 区.
 Area #1 `Variable Size' containing Subareas 2-2
  Total size 000000002f000000 Minimum Subarea size 00400000
   Area  Subarea                Start Addr
      1        2          000007FF00000000
                              Subarea size
                                  788529152
    [
      Base = 000007FF00000000 Prot = RW  Size =        788529152 State = COM
    ]
 Area #2 `Redo Buffers' containing Subareas 1-1
  Total size 000000000077d000 Minimum Subarea size 00001000
   Area  Subarea                Start Addr
      2        1          000000000C090000
                              Subarea size
                                  07852032
    [
      Base = 000000000C090000 Prot = RW  Size =          7852032 State = COM
    ]


--//看看第一个Bucket 0.
FREE LISTS:
 Bucket 0 size=32
  Chunk      7ff0b000088 sz=        0    kghdsx
                         ~~~~~~~~~~~~~

SYS@test> oradebug peek 0x7ff0b000088 32
[7FF0B000088, 7FF0B0000A8) = 00000001 C0B38F00 00000000 00000000 0AC5DD00 00000000 0AC5DD00 00000000
                                     
--//00000001 = 1 ,仅仅1个字节,也就是这个chunk size=0,不过注意记录的sz确实等于0,看下划线内容.
--//这样后面的信息如何保存,也许这个chunk非常特殊,kghdsx表示什么,我感觉这个chunk非常特殊,似乎表示开始.

SYS@test> oradebug peek 0x0AC5DD00 24
[00AC5DD00, 00AC5DD18) = 0B000098 000007FF 0B000098 000007FF 00000028 00000000

--//0AC5DD60-0AC5DD00 = 0x60 = 60 = 96
--//96/4 = 24,反向验证free list每个bucket占用24字节.
--//0x28 = 40,验证我前面的判断表示这个bucket最大的chunk size不能大于40.

--//仅仅启动到mount,free list都是null的.看看 Bucket 30,反向验证是否正确.
--//注意一个细节,整个测试最好不要执行任何sql语句,尽量减少使用chunk的情况.
 Bucket 30 size=272
  Chunk      7ff013bd300 sz=      272    free      "               "

--//30 = 0x1e,24=0x18
--//0AC5DD00 + 0x18 * 0x1e = 0xac5dfd0

SYS@test> oradebug peek 0xac5dfd0 24
[00AC5DFD0, 00AC5DFF0) = 013BD310 000007FF 013BD310 000007FF 00000118
                         ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
--//000007FF013BD310  - 0x10 = 0x7FF013BD300,正好对上.

--//0x118 = 280,0x48 = 72  ,0x28 = 40
--//280-72 = 208 , 208/8 = 26
--//280-40 = 240,  240/8 = 30
--//确实第16-19字节每个bucket增加8.

--//ac5dfd0-0x18 = 0xac5dfb8,bucket 29
SYS@test> oradebug peek 0xac5dfb8 24
[00AC5DFB8, 00AC5DFD0) = 0AC5DFB8 00000000 0AC5DFB8 00000000 00000110 00000000

--//ac5dfd0+0x18 = 0xac5dfe8,,bucket 31
SYS@test> oradebug peek 0xac5dfe8 24
[00AC5DFE8, 00AC5E000) = 0AC5DFE8 00000000 0AC5DFE8 00000000 00000120 00000000

--//确实第16-19字节基本可以确定表示这个bucket的最大chunk size是该数值-1.

3.启动到open,再次转储,步骤略:

 Bucket 251 size=12376
  Chunk      7ff00188010 sz=    16384    free      "               "
  Chunk      7feff84ac88 sz=    13560    free      "               "
  Chunk      7ff003a1000 sz=    16384    free      "               "
 Bucket 252 size=16408

--//可以发现 Bucket 251链接的是chunk size>= 12376 and <=16408-1 的chunk.
--//这样最小chunk size 是 32字节.bucket 0 chunk size >=32 <=40-1 的chunk.
 Bucket 0 size=32
  Chunk      7ff0b000088 sz=        0    kghdsx
--//sz=0 应该具有某种特殊意义.我不知道.

4.验证第16-19字节是否表示这个bucket的最大chunk size是该数值-1.

--//重新启动到mount状态.再次转储,步骤略:
--//单独保存free list部分为文件a.txt

$ grep Bucket a.txt | cut -d= -f2 | awk 'NR==1 {a=$1} NR>1 {print $1-a;a=$1}'| uniq -c
    179 8
     10 16
     50 48
      1 72
      1 8
      1 16
      1 4096
      1 536
      3 8
      1 608
      1 8
      1 2976
      1 8
      1 4032
      1 16384
      1 32768
--//Sum = 254

--//简单解析执行过程,避免以后忘记.
--//grep Bucket a.txt | cut -d= -f2 ,过滤含有Bucket行,再使用cut以=作为分隔符号,取第2个字段就是size=后面的值
D:\>grep Bucket a.txt | head -4
 Bucket 0 size=32
 Bucket 1 size=40
 Bucket 2 size=48
 Bucket 3 size=56

D:\>grep Bucket a.txt | cut -d= -f2| head -4
32
40
48
56
--//awk "NR==1 {a=$1} NR>1 {print $1-a;a=$1}" 就是做上下相减操作.
--//uniq -c  -c 表示prefix lines by the number of occurrences

--//看前面的输出,开始以为我计算错误,仔细检查发现没有问题.
--//可以看出oracle每个bucket增加的大小并非线性增加,中间出现仅仅增加8字节的情况.说明oracle一直在调整算法,避免内存浪费.或
--//者讲避免ora-04031错误.

d:\tmp> oerr ora 4031
04031, 00000, "unable to allocate %s bytes of shared memory (\"%s\",\"%s\",\"%s\",\"%s\")"
// *Cause:  More shared memory is needed than was allocated in the shared
//          pool or Streams pool.
// *Action: If the shared pool is out of memory, either use the
//          DBMS_SHARED_POOL package to pin large packages,
//          reduce your use of shared memory, or increase the amount of
//          available shared memory by increasing the value of the
//          initialization parameters SHARED_POOL_RESERVED_SIZE and
//          SHARED_POOL_SIZE.
//          If the large pool is out of memory, increase the initialization
//          parameter LARGE_POOL_SIZE.
//          If the error is issued from an Oracle Streams or XStream process,
//          increase the initialization parameter STREAMS_POOL_SIZE or increase
//          the capture or apply parameter MAX_SGA_SIZE.

--//179+10+50+1 = 240,贴出其中一段:
 Bucket 238 size=3976
 Bucket 239 size=4024
 Bucket 240 size=4096
 Bucket 241 size=4104  --//出现上下相减等于8的情况.
 Bucket 242 size=4120
 Bucket 243 size=8216
 Bucket 244 size=8752
 Bucket 245 size=8760
 Bucket 246 size=8768
 Bucket 247 size=8776  --//出现上下相减等于8的情况.
 Bucket 248 size=9384
 Bucket 249 size=9392
 Bucket 250 size=12368
 Bucket 251 size=12376  --//出现上下相减等于8的情况.
 Bucket 252 size=16408
 Bucket 253 size=32792
 Bucket 254 size=65560
--//上下相减 48,72 8,16....
--//可以想象在具体应用中一定许多chunk集中在size=4024 4096 4104 4120 附近.不然oracle不会做这样的改进.

--//换一个方式验证:
--//free list区 bucket 0在 00000000 0AC5DD00 位置.

SYS@test> oradebug peek 0x0AC5DD00 24
[00AC5DD00, 00AC5DD18) = 0B000098 000007FF 0B000098 000007FF 00000028 00000000

--//0AC5DD00 +0x10 地址保存chunk size .

SYS@test> oradebug peek 0x0AC5DD10 8
[00AC4DD10, 00AC4DD18) = 00000028 00000000

--//继续昨天的测试,今天启动到mount后,发现free list开始地址出现变动.

SYS@test> oradebug peek 0x7ff0ac00088 32
[7FF0AC00088, 7FF0AC000A8) = 00000001 C0B38F00 00000000 00000000 0AC4DD00 00000000 0AC4DD00 00000000

--//开始位置出现在0x0AC4DD00

SYS@test> oradebug peek 0x0AC4DD10 8
[00AC4DD10, 00AC4DD18) = 00000028 00000000

--//0AC4DD10 = 180673808

$ seq 0 1 254 | tr -d '\r' | xargs -IQ  echo "obase=16;180673808+Q*24"| bc | tr -d '\r'| awk '{print "oradebug peek 0x" toupper($1),4}'
--//输出略.使用tr -d '\r'主要原因是cygwin seq,bc的输出多了\r字符.

$ seq 0 1 254 | tr -d '\r' | xargs -IQ  echo "obase=16;180673808+Q*24"| bc | tr -d '\r'| awk '{print "oradebug peek 0x" toupper($1),4}'  > b.txt

SYS@test> oradebug setmypid
Statement processed.
SYS@test> @ b.txt
[00AC4DD10, 00AC4DD14) = 00000028
[00AC4DD28, 00AC4DD2C) = 00000030
[00AC4DD40, 00AC4DD44) = 00000038
[00AC4DD58, 00AC4DD5C) = 00000040
...
[00AC4F360, 00AC4F364) = 00000FB8
[00AC4F378, 00AC4F37C) = 00001000
[00AC4F390, 00AC4F394) = 00001008
[00AC4F3A8, 00AC4F3AC) = 00001018
[00AC4F3C0, 00AC4F3C4) = 00002018
[00AC4F3D8, 00AC4F3DC) = 00002230
[00AC4F3F0, 00AC4F3F4) = 00002238
[00AC4F408, 00AC4F40C) = 00002240
[00AC4F420, 00AC4F424) = 00002248
[00AC4F438, 00AC4F43C) = 000024A8
[00AC4F450, 00AC4F454) = 000024B0
[00AC4F468, 00AC4F46C) = 00003050
[00AC4F480, 00AC4F484) = 00003058
[00AC4F498, 00AC4F49C) = 00004018
[00AC4F4B0, 00AC4F4B4) = 00008018
[00AC4F4C8, 00AC4F4CC) = 00010018
[00AC4F4E0, 00AC4F4E4) = 00000000
--//最后1个00000000.

SYS@test> @ t
TRACEFILE
-----------------------------------------------------------------
D:\APP\ORACLE\diag\rdbms\test\test\trace\test_ora_900.trc

$ grep "^\[" test_ora_900.trc  | cut -d= -f2 | sed -n -e '1,$s/^ //p' |   awk '{print strtonum("0x"$0)}' | awk 'NR==1 {a=$1} NR>1 {print $1-a;a=$1}'| uniq -c
    178 8
     10 16
     50 48
      1 72
      1 8
      1 16
      1 4096
      1 536
      3 8
      1 608
      1 8
      1 2976
      1 8
      1 4032
      1 16384
      1 32768
      1 -65560
--//Sum = 254
--//出现178 8是正常的,因为这次计算使用最大值.
--//简单说明: grep "^\[" test_ora_900.trc  | cut -d= -f2 | sed -n -e '1,$s/^ //p' 过滤开头[的行,取分隔符=的第2字段,删除
--//开头的空格.
--//awk '{print strtonum("0x"$0)}' 转换为10进制数字.
--//awk 'NR==1 {a=$1} NR>1 {print $1-a;a=$1}' 上下相减
--//uniq -c 压缩输出.

Bucket 239 size=4024
Bucket 240 size=4096
Bucket 241 size=4104  --//出现上下相减等于8的情况.
Bucket 242 size=4120

$ seq 100000 | xargs -IQ echo "select Q from dual;" | sqlplus / as sysdba > /dev/null
SYS@test> select count(*) ,ksmchsiz from x$ksmsp where ksmchsiz between  4000 and 4120  group by ksmchsiz order by 2;
  COUNT(*)   KSMCHSIZ
---------- ----------
        11       4000
        63       4008
         1       4024
         3       4032
         2       4040
         2       4048
         2       4056
        39       4072
        14       4080
         1       4088
      5957       4096
         1       4104
         4       4112
       145       4120
14 rows selected.
--//我的测试环境语句太少,不过还是可以看出KSMCHSIZ=4120有许多.某种意义看出oracle故意这样设置.

5.总结:
--//前面已经展示free list如何链接的.仅仅相差0x10字节

--//free list在fixed区,并且每个bucket占用24字节,开始0-7字节表示free list地址的尾部,8-15表示free list地址的头部,16-23字节
--//表示该buckect free list 链接的chunk 最大chunk大小 -1,我开始猜测16-23字节相关内容时浪费一点点时间.

--//12c free list chunk size大小做了一些改进,每个bucket增加的大小并非线性增加,中间出现仅仅增加8字节的情况.说明oracle一直
--//在调整算法,避免内存浪费.或者讲避免ora-04031错误.在具体应用中一定许多chunk集中在size=4024 4096 4104 4120 附近.不然
--//oracle不会做这样的改进.补充在11g下也测试发现从11g就开始这样设计.

--//测试在mount下进行,不过不应该影响测试结论.

--//windows下测试太麻烦了,浪费大量时间,cygwin不够灵活,遇到输出\r字符的问题.

--//写的很乱,主要记录我当时的思考以及分析过程,整个分析过程夹杂了我许多猜测,术语也使用不对,不知道如何表达.
作者:lfree原文地址:https://www.cnblogs.com/lfree/p/18242705

%s 个评论

要回复文章请先登录注册