在运行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中文网,转载请注明出处,感谢您的尊重!