在运行Oracle 数据库的linux 服务器上，某个时间段的每分钟负载会突然上升到40 以上，在进程队列里看到kswapd0 出现，导致数据库
在运行oracle 数据库的linux 服务器上，某个时间段的每分钟负载会突然上升到40 以上，在进程队列里看到kswapd0 出现，导致数据库无响应，持续时间数分钟。
对于应用而言，这个时间段有明显的停滞感，像系统已经挂掉了一样。
如果这是发生在oracle rac 环境中某一个节点上，那么这个节点就可能会重启。
这属于非常严重和致命的问题。
1. 问题
环境是这样，数据库服务器的内存96gb ，操作系统linux redhat 5 ，采用hugepages 管理部分内存，运行一个数据库实例，数据库系统版本为10.2.0.4 。
数据库实例中sga_max_size 的值为48gb, pga_aggregate_target 的值为24gb 。
还有个实例为asm ，用于存储数据库的数据文件等。
性能摇摆期间的top 显示的结果如下：
top - 13:21:11 up 49 days, 21:52, 4 users, load average: 42.76, 14.42, 6.12
tasks: 471 total, 26 running, 444 sleeping, 0 stopped, 1 zombie
cpu(s): 87.2%us, 12.2%sy, 0.0%ni, 0.1%id, 0.1%wa, 0.1%hi, 0.2%si, 0.0%st
mem: 98989932k total, 98152840k used, 837092k free, 2056k buffers
swap: 50331636k total, 12554316k used, 37777320k free, 37715224k cached
pid user pr ni virt res shr s %cpu %mem time+ command
1057 root 20 -5 0 0 0 r 100.2 0.0 991:39.65 [kswapd0]
zzz ***fri jun 29 13:21:35 cst 2012
top - 13:21:39 up 49 days, 21:52, 4 users, load average: 28.99, 13.85, 6.19
tasks: 471 total, 2 running, 468 sleeping, 0 stopped, 1 zombie
cpu(s): 0.2%us, 8.4%sy, 0.0%ni, 91.3%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
mem: 98989932k total, 98104680k used, 885252k free, 3028k buffers
swap: 50331636k total, 12801004k used, 37530632k free, 37606456k cached
pid user pr ni virt res shr s %cpu %mem time+ command
1057 root 20 -5 0 0 0 r 100.3 0.0 992:07.44 [ kswapd0 ]
12530 root 15 0 13032 1400 812 r 0.7 0.0 0:00.03 top -b -c -n 2
1376 root 10 -5 0 0 0 s 0.3 0.0 22:00.23 [scsi_eh_1]
可以明显看到服务器的一分钟负载上升的很厉害，都到42 了，而正常才4 左右。在运行的进程队列中，看到 kswapd0 。
操作系统每过一定时间就会唤醒kswapd ，看看内存是否紧张，如果不紧张，则睡眠，在 kswapd 中，有2 个阀值, pages_hige和pages_low,当空闲内存页的数量低于 pages_low 的时候, kswapd进程就会扫描内存并且每次释放出32 个free pages,直到 free page 的数量到达pages_high.
通过检查vmstat 的输出结果，发现在那个时间段内，系统的页面换入换成现象很严重。
zzz ***fri jun 29 13:22:05 cst 2012
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
7 0 13022188 919216 3064 37429916 27 17 203 559 0 0 3 1 95 1 0
4 0 13040224 914712 3116 37411924 680 2196 1450 2844 1387 1654 13 10 77 0 0
2 0 13058536 919060 3216 37395064 104 1444 1118 1492 1235 839 16 9 75 0 0
zzz ***fri jun 29 13:22:35 cst 2012
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
9 0 13573224 912300 3356 36885376 27 17 203 559 0 0 3 1 95 1 0
8 0 13573088 913408 3368 36885224 276 0 3740 5643 1643 7707 31 9 60 0 0
1 0 13572892 913300 3368 36885920 252 0 374 3955 2209 9632 14 9 77 0 0
就是说，问题是内存紧张了，导致了交换分区频繁使用到。kswapd0 进程需要换入换出虚拟内存磁盘空间，导致了系统出现短时间摇摆。
操作系统的物理内存有25576 个page 没有被使用，所以肯定会有kswap 进程执行虚拟内存换页操作。
2. 分析
问题既然发生在内存使用上，但我们的服务器物理内存配置是96gb ，数据库实例的内存配置也是合理的。
但在vmstat 确实有交换分区的换页情况发生。
我们需要分析的是，这96gb 的内存都是如何使用的呢？
在环境介绍中，我们介绍了使用大内存管理模式管理内存的。因此，我们首先查询系统内存信息中关于大内存的使用情况。
[root@db3 ~]# cat /proc/meminfo |grep -i huge
hugepages_total: 25576
hugepages_free: 25517
hugepages_rsvd: 4
hugepagesize: 2048 kb
哇，看到结果大吃一惊。大内存有25517 个页面没有使用，一个页面大小是2mb ，也就是说有51034mb 内存被大内存管理机制限制了，属于空闲状态，而系统上其他进程也无法使用到。只有59 个页面合计118mb 的内存使用到了。
（注，为什么新进程如何使用到该内存区域，而是使用虚拟内存空间呢？这是一个疑问。可能是新数据库实例的sga 已经使用了剩余的48 内存，还不够用，所以用到虚拟内存。）
在系统配置中，hugepages 的大小设置为25576 ，计48gb 内存，是物理内存的一半。
[root@db3 ~]# sysctl -p
vm.nr_hugepages = 25576
使用ipcs –m 看到oracle 用户下使用的共享内存段如下所示：
------ shared memory segments --------
key shmid owner perms bytes nattch status
0xb0af65c0 3047451 oracle 600 132120576 13
0x4507bd98 3702814 oracle 640 51541704704 132
最大的51541704704 字节，计49154mb 。这个sga 中所有 'shared_pool_size' , 'large_pool_size' , 'java_pool_size' , 'streams_pool_size' , 'db_cache_size' 大小之和。
oracle 用户的共享内存段完全没有使用到hugepages 。
再检查系统日志，发现之前有一个oracle 的实例使用到该hugepages ，而现在的实例是后来启动的，所以使用到另外的内存。
后来前一个实例关闭了，但hugepages 中的内存空间却一直空闲下来，新的实例也不能使用到这个内存空间。
3. 解决
问题分析到这里，，其实已经有解决方法了。
我们重启了一下数据库实例，就可以使用该hugepages 内存空间。
如果实例不能重启，我们也可以通过设置nr_hugepages 的值降低设置。但这只是个人建议，不排除有新的问题出现。
4. 技术hugepages
如果需要增大hugepages 大小，需要重启操作系统。
如果您认为这就是一个内存参数值，可以使用sysctl –w 修改的。这点是不正确的。这里涉及到内存管理方面，hugepages 需要大量连续的内存区域，否则严重的内存碎片会影响到系统的性能。
linux 的hugepages 技术随着近年大内存服务器陆续上市，逐步推广使用，因此关于hugepages 的问题也随着而来。
本文是在hugepages 使用中遇到的问题的解决分析总结。
