hugepages使用出现kswapd导致系统负载突然上升

在运行Oracle 数据库的linux 服务器上，某个时间段的每分钟负载会突然上升到40 以上，在进程队列里看到kswapd0 出现，导致数据库无响应，持续时间数分钟。

对于应用而言，这个时间段有明显的停滞感，像系统已经挂掉了一样。

如果这是发生在Oracle RAC 环境中某一个节点上，那么这个节点就可能会重启。

这属于非常严重和致命的问题。

(miki西游 @mikixiyou 文档原文链接: http://mikixiyou.iteye.com/blog/1573976 )

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 需要大量连续的内存区域，否则严重的内存碎片会影响到系统的性能。

 

网友 Eagle Fan 的weblog 中一篇，详细介绍了该技术，链接如下：

http://www.dbafan.com/blog/?p=435

linux 的hugepages 技术随着近年大内存服务器陆续上市，逐步推广使用，因此关于hugepages 的问题也随着而来。

本文是在hugepages 使用中遇到的问题的解决分析总结。