RAC环境下Memory System Deconfigured
这是客户的一个Oracle9iR2 RAC数据库环境,数据库版本为Oracle 9.2.0.8,主机为IBM P55a小型机。最初客户集群环境运行稳定,后来一台主机出现硬件故障退出集群,问题出现在主机维修完毕之后,当故障主机重新加入现有环境运行,客户发现应用性能出现衰减,前端收费系统响应缓慢,反而不如一个节点工作时的性能。
首先可以看一下这个系统的逻辑读变化曲线,图1-10清晰地显示在17日左右系统变成单节点运行后,逻辑读有了一个双倍的攀升变化,非常线性和清晰:
图1-10 系统的逻辑读变化曲线
现在的问题是,两个节点运行反而不如当初的单节点运行,那么很有可能是新恢复运行的节点存在问题。登录该主机首先使用vmstat来收集系统信息,从以下摘要数据可以看到,系统的内存消耗殆尽,Page In/Out较高,同时Wait较高:
p55a1#vmstat 2
System configuration: lcpu=4 mem=1840MB
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
0 0 802203 2591 0 22 51 64 247 0 600 3182 1434 3 1 91 5
0 3 802477 2776 0 38 151 345 1606 0 629 2509 1270 1 1 87 10
0 1 801897 3098 0 207 76 0 0 0 910 3306 1762 3 2 74 22
0 0 802229 2549 0 131 92 193 692 0 2138 12989 6000 10 6 69 15
3 0 801876 2812 0 71 26 0 0 0 953 5782 2145 10 2 79 8
1 1 801877 2814 0 139 95 141 503 0 1095 6617 2810 12 3 70 14
0 2 801887 2546 0 128 0 0 0 0 780 3566 1909 5 2 79 14
0 2 801883 3042 0 150 284 401 4301 0 1079 3067 1820 3 2 56 39
0 1 802061 2532 0 162 0 0 0 0 1191 5444 2630 2 2 81 14
1 1 802060 3193 0 51 270 381 2387 0 704 2468 977 3 1 77 18
1 3 802535 2827 0 256 201 338 2011 0 975 2808 1624 11 2 51 36
0 4 802852 2606 0 263 221 287 1535 0 1181 3217 2044 5 2 51 42
1 2 802455 2838 0 339 166 258 1154 0 1181 4040 2181 13 2 47 37
通过topas可以做进一步的诊断,从图1-11的输出中同样可以看到类似数据,系统的I/O Wait较高,Paging频繁,而磁盘hdisk5和hdisk6的Busy程度达到了近100%:
图1-11 执行topas命令的输出
这说明由于主机的交换频繁导致了I/O负荷升高,从而导致了数据库响应缓慢。那么为什么会出现这种问题呢?内存的紧张和交换频繁直接和数据库的内存使用有关。
登录数据库,查看一下SGA设置就能够明白问题的原因所在(见如下代码):
p55a1$sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.8.0 - Production on Tue Dec 2 10:34:20 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SQL> show sga
Total System Global Area 2031584960 bytes
Fixed Size 743104 bytes
Variable Size 956301312 bytes
Database Buffers 1073741824 bytes
Redo Buffers 798720 bytes
我们注意到数据库的SGA设置,分配了大约2GB的内存,而根据如下系统显示,主机配置的内存也仅为2GB:
System configuration: lcpu=4 mem=1840MB
看来问题的原因已经找到,由于数据库的SGA设置过高,导致了过高的内存消耗,使得系统在业务繁忙时段产生了大量的交换,影响了系统性能。那么解决这个问题的方式是要么降低SGA,要么扩展系统内存。
但是还有一个问题,为什么以前一切是正常的,而机器修复后反而出现了问题呢?其实系统除了维修并未做其他数据库参数方面的变更。
适当猜测加上询问客户和查看记录就发现了进一步的原因,那就是在维修之前该主机共有4GB内存,维修之后只剩下了2GB,而客户并未主动变更过,那么显然还有故障存在在主机上(虽然errpt并未显示任何警告)。
在机房通过笔记本连接P55A小型机后端的HMC1口,通过浏览器连接主机,发现根本原因所在,原来是有两个内存被Deconfigured了(见图1-12):
图1-12 Memory Deconfigration
也就是说可能这两条内存出现了故障,或者可能是内存插槽有问题,导致2GB的内存未被加载,这才是这次故障的根本原因。通过联系硬件厂商,解决了内存故障后,数据库系统恢复正常。
建议继续学习:
- Linux服务器性能评估 (阅读:8152)
- 查看 CPU, Memory, I/O and NetFlow (阅读:6414)
- ORACEL RAC 字符集 (阅读:4613)
- Linux 64位, MySQL, Swap & Memory 优化 (阅读:4460)
- memory prefetch浅析 (阅读:4786)
- Oracle RAC廉价数据仓库解决方案 (阅读:2600)
- Oracle RAC中的RDS内部互联 (阅读:2588)
- kswapd 进程占用过多资源导致RAC宕机 (阅读:2455)
- RAC的负载均衡 (阅读:2562)
- oracle RAC DRM基本概念 (阅读:1970)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:eygle@eygle.com(eygle) 来源: Oracle Life
- 标签: Memory RAC
- 发布时间:2011-03-01 22:39:53
- [65] Oracle MTS模式下 进程地址与会话信
- [65] Go Reflect 性能
- [64] 如何拿下简短的域名
- [59] android 开发入门
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 图书馆的世界纪录
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [46] 读书笔记-壹百度:百度十年千倍的29条法则