mysql负载突然飙升_hugepages使用出现kswapd导致系统负载突然上升

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

本文原创发布php中文网，转载请注明出处，感谢您的尊重！