Automatic Memory Management简析

从11g开始引入了AMM(Automatic Memory Management)的概念，AMM管理了SGA+PGA的内存分配，它允许将内存在SGA和PGAs之间进行转移，你只需要指定MEMORY_TARGET一个参数即可，剩下的事情全部交给oracle自己来做。

这里首先解释几个名词：

• System global area (SGA)

  SGA是一组共享内存结构，作为SGA组件，包含了一个oracle实例中的数据和控制信息。所有server和后台进程都共享SGA，SGA的数据包括缓存数据块和共享SQL区。

• Program global area (PGA)

  PGA是一块非共享的内存区域，单独存放每个oracle进程的数据和控制信息。当进程开始运行时oracle就会自动为这个进程创建pga，每个服务进程和后台进程都有一个PGA，而所有PGA的集合就构成了整个实例的PGA，数据库的初始化参数设置了整个实例的PGA大小。

• User global area (UGA)

  UGA是每个用户会话的内存

• Software code areas

  Software code areas是用来存放要执行或可以执行的代码，Oracle数据库代码存储在软件区域中，该区域通常与用户程序位于不同的位置，即更为排他或受保护的位置。

AMM几个重要的参数如下：

• MEMORY_MAX_TARGET
• MEMORY_TARGET
• SGA_MAX_SIZE
• SGA_TARGET
• PGA_AGGREGATE_TARGET

AMM的功能由内存管理器进程实现，简称MMAN。对于进程的私有内存，可以被释放然后用于共享。这样就会产生很多重要的结果，在一个有很多复杂sql的系统中，含有很多并行，进程通常会进行大量的排序和表关联。这些操作十分消耗MEMORY_TARGET里的空闲内存。而越来越多这样的进程启动时，则需要更多的私有内存，MMAN则会转向SGA尝试将共享的内存重新分配到私有内存当中。

当PGA需要更多的内存时,MMAN会扫描SGA的空闲列去查找那些没有被使用的内存块，MMAN合并这些空闲的块，直到创建一个连续的块，其大小与granule的大小相同。然后这个granule会从SGA中解锁，然后重新交还给操作系统去用于作为PGA当中的私有内存。

这里就会有一个疑问，oracle到底是如何将SGA当中共享的内存转移到私有的的PGA当中去的呢？传统的sysv shm接口应该是无法从单个共享的内存段中回收和释放内存的，所以需要深入研究oracle是如何实现的。

检查实例的共享内存id

[oracle@localhost ~]$ sysresv

IPC Resources for ORACLE_SID "test" :
Shared Memory:
ID		KEY
4456458 	0x00000000
4489227 	0x00000000
4521996 	0x196836c4
Semaphores:
ID		KEY
983047  	0x86cb91e8
Oracle Instance alive for sid "test"

检查对应的sysv SHM段

[oracle@localhost ~]$ ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 3637250    root      644        80         2                       
0x00000000 3670020    root      644        16384      2                       
0x00000000 3702789    root      644        280        2                       
0x00000000 4456458    oracle    640        4096       0                       
0x00000000 4489227    oracle    640        4096       0                       
0x196836c4 4521996    oracle    640        4096       0

这里有些很奇怪的地方，我设置的memory_target参数为2g，而这里sysv shm段每个却只有4k，那SGA包含的共享内存到哪去了？根据前面对SGA的定义，可以通过检查oracle实例的进程绑定的内存。

[oracle@localhost ~]$ pmap `pgrep -f lgwr`
25285:   ora_lgwr_test
0000000000400000 189264K r-x--  /oracle/product/11.2.0/dbhome_1/bin/oracle
000000000bed4000   2020K rw---  /oracle/product/11.2.0/dbhome_1/bin/oracle
000000000c0cd000    348K rw---    [ anon ]
000000001e039000    440K rw---    [ anon ]
0000000060000000      4K r--s-  /dev/shm/ora_test_4456458_0
0000000060001000  16380K rw-s-  /dev/shm/ora_test_4456458_0
0000000061000000  16384K rw-s-  /dev/shm/ora_test_4456458_1
0000000062000000  16384K rw-s-  /dev/shm/ora_test_4489227_0
0000000063000000  16384K rw-s-  /dev/shm/ora_test_4489227_1
0000000064000000  16384K rw-s-  /dev/shm/ora_test_4489227_2
0000000065000000  16384K rw-s-  /dev/shm/ora_test_4489227_3
0000000066000000  16384K rw-s-  /dev/shm/ora_test_4489227_4
0000000067000000  16384K rw-s-  /dev/shm/ora_test_4489227_5
...

通过pmap的输出可以看到，oracle采用/dev/shm来实现共享内存，会有多个16MB大小的文件来匹配oracle服务进程的地址空间，这里是Linux的面向POSIX的SHM实现，任何东西包括空闲内存都是一个文件。

Linux共享内存：

共享内存：

共享内存是进行程序之间的数据传输的一个非常有效率的方式，允许一个或多个进程来通过出现在其所有虚拟地址空间中的内存进行通信。POSIX,system-v提供了一个标准的API来使用共享内存。POSIX共享内存调用是根据UNIX原理，即如果你对一个对象执行输入/输出操作，则该对象必须是一个文件。所以当对一个POSIX共享内存对象进行读取和写入时，后者必须被当做一个文件。POSIX共享内存对象是一个内存映射文件，POSIX共享内存文件都是由/dev/shm挂载的tmpfs文件系统来提供。目前仅有两个专门的POSIX共享内存系统调用，即shm_open和shm_unlink，用来打开和unlink调用文件。

SYS-V共享内存段的大小在创建的时候就是固定的，相反，对于由文件或POSIX共享内存对象支持的映射，我们可以使用ftruncate（）来调整基础对象的大小，然后使用munmap（）和mmap（）重新创建该映射。

为什么在AMM中使用POSIX共享内存？

为了用一个单独的memory_target参数来管理SGA和PGA的大小，并且对于单独的共享内存段来进行收缩和释放内存的操作来说，sysV SHM接口则并没有那么的具有弹性。所以oracle通过使用Linux的面向POSIX的SHM来实现，而要实现POSIX共享内存，我们需要ramfs或者tmpfs。在oracle实例启动以后，可以看到/dev/shm下面有一堆文件。

由于SGA的内存分配被分成了很多小块，oracle会更加容易去释放SGA的内存返还给操作系统，进而分配到那些系统进程当中。

SQL> show parameter memory_target;

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
memory_target			     big integer 2G

这里已经分配了2048M的内存，当memory_target小于1g时，granule大小是4M，超过1g时，granule大小则为16M。这里可以检查一下已经分配了多少个granules

[oracle@localhost ~]$ pmap `pgrep -f lgwr` | grep 16384K | wc -l
128

而总大小为128*16M=2G。

也可以直接从/dev/shm系统目录下去查看

[oracle@localhost ~]$ ls -l /dev/shm | grep test
-rw-r----- 1 oracle oinstall 16777216 Aug 12 17:42 ora_test_4456458_0
-rw-r----- 1 oracle oinstall 16777216 Aug 12 17:33 ora_test_4456458_1
-rw-r----- 1 oracle oinstall        0 Aug 12 17:03 ora_test_4489227_0
-rw-r----- 1 oracle oinstall        0 Aug 12 17:03 ora_test_4489227_1
-rw-r----- 1 oracle oinstall        0 Aug 12 17:03 ora_test_4489227_10
-rw-r----- 1 oracle oinstall 16777216 Aug 12 17:33 ora_test_4489227_100
-rw-r----- 1 oracle oinstall 16777216 Aug 12 17:08 ora_test_4489227_101
-rw-r----- 1 oracle oinstall 16777216 Aug 12 17:03 ora_test_4489227_102
...

如果没有设置MEMORY_TARGET，/dev/shm下面的共享内存段则会消失，而MMAN会转向值使用正常的共享内存，也就是ipcs -ma命令可以看到的那些。

/dev/shm下面有很多内存块大小是为0的，这些内存块是由于需要空间或PGAs区域时被破坏掉的受害者。如果通过之前的pmap输出仍然可以看到这些内存映射到地址空间，但是这些并不会被使用因为oracle知道这些内存实际上是已经释放的。

如果修改增大pga_aggregate_target的参数，则会看到有很多原本为16M大小的文件会变成0。

这里就要提到一个关于MEMORY_TARGET的常见的错误，比如你没有设置/dev/shm为一个合适的值，则oracle会在分配新的POSIX共享内存失败，这样就会导致你无法使用MEMORY_TARGET参数，错误如下

SQL> ORA-00845: MEMORY_TARGET not supported on this system

也可以参考之前的一篇文章
https://www.xbdba.com/2019/04/11/ora-00845-memory_target-not-supported-on-this-system/