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

码上飞

码上飞（CodeFlying） 是一款AI自动化开发平台，通过自然语言描述即可自动生成完整应用程序。

138

查看详情

在运行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 使用中遇到的问题的解决分析总结。