Tuning VMM kernel parameter in AIX for Oracle

Updated@2013-01-30
对于运行Oracle数据库的AIX操作系统VMM(Virtual Memory Management)层面的系统内核参数如何进行调整,这是一个很古老的话题。这篇文章力图解释一些概念,同时与时俱进地提出一些设置的建议。

通常对VMM系统内核调优的目的,在于最大限度的保护计算内存页(computational memory)不被page-out到paging space中,因为对于计算内存页(特定于Oracle数据库来说就比如是SGA和PGA)来说被page-out出去的内存页总在之后的某一时刻又会被重新page-in,通常这样会对系统性能产生负面影响。另外对于像Oracle数据库这样拥有自己的数据缓存机制(data buffer cache)的数据库应用来说,保护计算内存页更显得格外重要。

在IBM AIX 5.3 ML1之前,对于作为Oracle Database Server用途并且使用裸设备作为Datafile存储的的AIX操作系统内核参数调优的经验通常如下:

maxperm%=maxclient%=(通常是一个很低的值,小于20或者30)
设置较小maxperm%值的原因在于,如果文件内存页在内存中的比例高过该参数值,那么VMM换页算法将只从文件内存页中进行偷页。将maxperm%值降低就意味着有更大的机会让VMM只从文件内存页中偷页。
minperm%=5(通常是一个比maxperm%更低的值)
lru_file_repage = 1(这是默认值)

比如以下的VMM参数设置就符合该种调优方式。

root@hostname:/> vmo -a |grep "maxclient%"
            maxclient% = 15            
root@hostname:/> vmo -a |grep "maxperm%"
              maxperm% = 15
root@hostname:/> vmo -a |grep "minperm%"
              minperm% = 10              
root@hostname:/> vmo -a |grep "lru_file_repage"
       	lru_file_repage = 1

但是实际上在AIX 5.3 引入了lru_file_repage参数之后,对于操作系统VMM层的内核参数调整方法已经发生了改变。现在的VMM参数调优建议应该如下。

maxperm%=maxclient%=(较高值,通常为90%)
因为较高的maxperm%值能够防止不必要的lrud进程运行,lrud进程是系统核心进程负责在需要的时候偷取内存页(stealing memory)。如果可以,maxperm%应该大于numclient%值(通过vmstat -v可以获得)。(如果服务器文件系统使用较多,那么此参数另有建议,参见后文)。
minperm%=(较低值,对于超过64G物理内存的服务器来说通常为20%,IBM甚至建议将该值设置为3%,在AIX6.1中该值已经默认为3%)
较低的minperm%值用以保证lru_file_repage参数作用不至于无法体现。通常minperm%值应该低于numperm%值(通过vmstat -v可以获得),如果当前的minperm%=5%满足需求那么可以不用修改。
strict_maxperm=0(这是默认值,表示这不是一个hard limit)
strict_maxclient=1(这是默认值,表示这是一个hard limit)
lru_file_repage = 0
当该参数设置为0的时候,VMM将会优先尝试从文件内存页中进行偷页操作,而不影响到计算内存页。在AIX6.1中该值已经默认为0。

更详细地看一下lru_file_repage参数是如何影响VMM偷页算法的。

由于空闲页低于了minfree参数值,或者其它的一些触发机制(比如说client page数量超过了maxclient%并且strict_maxclient=1)导致lrud进程要开始偷页操作,此时如果lru_file_repage =1(这是默认值)那么lrud进程将会根据多种内核参数和系统当前状况进行判断,可能是只从文件内存页中偷页也可能是不管内存段的类型从整个内存中进行偷页,这就可能导致计算内存页被page-out出去,而如果lru_file_repage =0,那么只要文件内存页(file memory)占内存的比值(numperm)高于minperm并且VMM确实能够从文件内存页中偷取到足够的内存以满足需求,那么就只会做文件内存页的page-out。因此,保护了Oracle数据库SGA在内存中的稳定性。

另外可以调整的参数包括:
page_steal_method = 1(应该为默认值)

参看如下解释:

The VMM maintains a logical list of free page frames that it uses to accommodate page faults. In most environments, the VMM must occasionally add to the free list by reassigning some page frames owned by running processes. The virtual-memory pages whose page frames are to be reassigned are selected by the VMM’s page-replacement algorithm. The VMM thresholds determine the number of frames reassigned.
By default in AIX 6.1, and optionally in AIX 5.3 the LRU algorithm can either use lists or the page frame table. Prior to AIX 5.3, the page frame table method was the only method available. The list-based algorithm provides a list of pages to scan for each type of segment.
You can disable the list-based LRU feature and enable the original physical-address-based scanning with the page_steal_method parameter of the vmo command. The default value for the page_steal_method parameter is 1, which means that the list-based LRU feature is enabled and lists are used to scan pages. If the page_steal_method parameter is set to 0, the physical-address-based scanning is used. The value for the page_steal_method parameter takes effect after a bosboot and reboot.

因此,对于作为Oracle数据库服务器的IBM AIX 5.3之后版本,VMM参数建议值如下。

minperm%=3
maxperm%=90
maxclient%=90
lru_file_repage=0
strict_maxperm=0
strict_maxclient=1
page_steal_method=1

然而如果数据库服务器中文件系统使用较多(比如数据文件存储在文件系统中,或者有大量的RMAN备份归档日志,或者有大量磁盘文件复制转移等操作),那么强烈建议设置maxperm%=maxclient%=(低值,20%或者10%),这是为了保障有安全的物理内存空闲,而不至于给文件内存页占据,因为如果maxclient%设置为90,那么意味着文件内存页可以占据更多的内存(也就是意味完全空闲的内存更低),虽然根据lru_file_repage=0的算法,偷页操作会从文件内存页中进行,但是这部分缓存的释放是需要时间的,也会需要大量IO和换页操作,当某个时间点,数据库服务器上突然出现大量需要消耗内存的操作,就可能导致大量的换页,从而消耗大量系统资源,影响数据库性能,并可能进一步导致数据库服务器的不稳定。这在很多客户系统中已经遇到这样的案例。

因此对于这样的系统,我们建议VMM参数设置如下。

minperm%=3
maxperm%=20
maxclient%=20
lru_file_repage=0
strict_maxperm=0
strict_maxclient=1
page_steal_method=1

修改VMM参数的命令如下。

#!/usr/bin/ksh
vmo -p -o minperm%=3;
vmo -p -o maxperm%=20;
vmo -p -o maxclient%=20;
vmo -p -o lru_file_repage=0;
vmo -p -o strict_maxperm=0;
vmo -p -o strict_maxclient=1;
vmo -r -o page_steal_method=1; 

IBM AIX 5L+TSM+Oracle10.2.0.3 RAC+ASM+RMAN经验谈

1. TSM(Tivoli Storage Manager)在产品易用性方面真是不如Veritas的NBU,甚至也不如HP的Omni DP。

2. 高端带库的I/O速度不弱于盘阵,跟I/O通道个数以及驱动器个数关系很大。

3. 使用2个channel往84块单盘300G的底层作了0+1 RAID的21个物理卷组成的ASM磁盘组中(好拗口 …)restore 2T大小的数据库耗时6小时。

4. 目前看来,所有的ASM磁盘组信息都没有存在任何配置文件中,无论是进入asmcmd还是选择v$asm相关视图,都是实时从PV头部读取的信息。所以在ASM使用外部冗余的磁盘组中一块PV坏掉以后,可以直接用dd来清除该磁盘组中所有其他disk的头部信息,然后重新创建磁盘组,然后用RMAN恢复数据库,这也是当ASM磁盘组崩溃以后唯一的修复方法。

5. 条带并不是越多越好。在这个环境中,112块disk在硬件级别做了RAID 0+1的条带和镜像,操作系统中对这112/2*300G=16T的存储做了56个PV,如果在创建LV的时候又选择了条带选项(二次条带化),那么读性能将会严重下降,每秒只能达到60M的读,而如果去除二次条带化,则读性能可以上升到每秒200M。
原因:在将数据写入做了二次条带化的存储上时,首先数据在操作系统级别被打散为56个stripe,然后每个stripe在硬件级别又再次被打散为56个stripe,这样并行写的性能是没有问题的,但是在读取的时候,由于请求的数据在硬件级别是被打散在56块disk中的,而硬件级别的缓存机制在读取一块disk上的数据时将会缓存相邻的大量数据,而这些缓存对于此次读取来说都是无用的,当从另外一个disk中再读取需要的数据时,缓存又需要被腾空再容纳这个disk上的数据,但是这次缓存中又只有很小一部分数据是有用的,因此当PV越多的时候,二次条带将导致越大的性能下降。

6. 10g的新功能change tacking貌似有些bug,在头天晚上启动了change tacking,然后做了level 0备份,2.1T的数据文件总共备份出200G的备份集,第二天做了level 1备份,居然备份出2.1T的备份集,也就是change tracking告诉RMAN在这一天里面所有的data block都发生了变化,所以RMAN备出了数据库中所有block,但是实际上这很明显是不可能的,因为当天的归档日志备份只有500多M,第三天仍旧是level 1备份,就比较正常了,当天产生60多G的归档日志,但是level 1备份只花费了3分钟,这是change tracking真正的威力显示了。