内存参数设置不合理导致数据库HANG
- - CSDN博客数据库推荐文章内存参数设置不合理导致数据库HANG. 2节点RAC，数据库忽然HANG住，重启一个实例后恢复正常. 故障时间段约为8:30-10:00，以下为alert报错：. Thread 2>
ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] [].
内存参数设置不合理导致数据库HANG
标签：
内存
参数
数据库
| 发表时间：2013-12-26 07:12 | 作者：zhou1862324
出处：http://blog.csdn.net
内存参数设置不合理导致数据库HANG
现象：
2节点RAC，数据库忽然HANG住，重启一个实例后恢复正常。
分析：
故障时间段约为8:30-10:00，以下为alert报错：
alert_crm2.log：
Mon May 27 06:54:26 2013
SUCCESS:> Mon May 27 07:32:24 2013
Thread 2> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] []
ORA-03135: 连接失去联系
Mon May 27 09:54:56 2013
Errors> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] []
ORA-03135: 连接失去联系
Mon May 27 09:54:56 2013
Errors> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] []
ORA-03135: 连接失去联系
Mon May 27 09:54:56 2013
Errors> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] []
ORA-03135: 连接失去联系
Incident> USER (ospid: 15258): terminating the instance
Mon May 27 09:55:05 2013
ORA-1092 :> ORA-00600: internal error code, arguments: [723], [109464], [127072], [memory leak], [], [], [], [] <-memory leak?
Incident> loadavg : 69.72 40.04 27.44
memory> swap info: free = 0.00M alloc = 0.00M total = 0.00M
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
0 S> #0 0x0000003e2d6d50e7 in semop () from /lib64/libc.so.6
#1 0x000000000778a4f6> #7 0x0000000003b87b4a in kjdrchkdrm ()
#8 0x0000000003a38c5a>
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 6261 27-May-13 09:00:40 404 7.5
End Snap: 6262 27-May-13 10:00:34 488 5.3
Elapsed: 59.90 (mins)
DB Time: 10,417.13 (mins)
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms)> gc current block 2-way 411,847 673 2 3.8 Cluster
gc>
*** 2013-05-27 07:26:41.101
Trace> (session) sid: 1645 ser: 1 trans: (nil), creator: 0x590fc76e0
flags: (0x51) USR/-> Dumping Session Wait History:
0:> wait_id=348204630 seq_num=17176 snap_id=1
wait> wait times (usecs) - max=infinite
wait> occurred after 228 microseconds of elapsed time
1:>
CRMM01_130527_0800.nmon.xlsx:
CPU Total CRMM01 User% Sys% Wait% Idle% CPU% CPUs
9:38:00 2.4 0.8 6.2 90.7 3.2 24
9:39:31 1.3 1 5.9 91.9 2.3 24
9:41:01 16 5 7.6 71.4 21 24
9:42:33 91.3 7.9 0.2 0.6 99.2 24 <===== CPU 99.2%Busy (When> Time PID %CPU %Usr %Sys Size ResSet ResText ResData ShdLib MinorFault MajorFault Command
8:07:34 773 0.76 0 0.76 0 0 0 0 0 0 0> 8:07:34 774 36.91 0 36.91 0 0 0 0 0 0 0 kswapd1 1.54 0
Memory MB CRMM01>
Paging> Node1: swap increased after 8:00.
CRMM01_130527_0800.nmon.xlsx:
Paging> 8:03:03 589 10.81 kswapd0
8:06:03 589 1.68>
通过以上的日志分析，大致发现客户的DB在故障时间段存在一些问题：
1.内存资源紧张（a.lmd0在进行一些内存释放的操作;b.free> 2.空闲SWAP页面紧张，大量的page in/out <==引发SWAP的原因是什么？什么进程占用内存导致SWAP？是不是有memory leak的现象？
3.严重的shared> 4.实例1的lmd0在9:42-9:44HANG住（STALL）， <==== 是否跟latch获取有关？
还未完全理清的时候，客户的DB又出现了HANG住的情况，这次客户做了systemstate> HANG ANALYSIS:
instances (db_name.oracle_sid):>
Chains> Chain 1 Signature Hash: 0xb52ba8a9
[b] Chain 2 Signature: 'latch:> Chain 2 Signature Hash: 0x985d217a
[c] Chain 3 Signature: 'latch:> Chain 3 Signature Hash: 0xb52ba8a9
Chain 1:
-------------------------------------------------------------------------------
Oracle> p2: 'number'=0x101
p3: 'tries'=0x0
time> short stack: <-ksedsts()+315<-ksdxfstk()+32<-ksdxcb()+1764<-sspuser()+112<-__restore_rt()<-semop()+7<-sskgpwwait()+980<-skgpwwait()+135<-kslges()+1163<-kslgetl()+556<-kksCheckToFreeCursorStat()+336<-kksLoadChild()+8989<-kxsGetRuntimeLock()+1794<-kksfbc()+6536<-kkspsc0()+2601<-kksParseCursor()+147<-opiosq0()+1827<-kpooprx()+350<-kpoal8()+908<-opiodr()+1178<-ttcpip()+1211<-opitsk()+1455<-opiino()+1026<-opiodr()+1178<-opidrv()+580<-sou2o()+90<-opimai_real()+145<-ssthrdmain()+177<-main()+215<-__libc_start_main()+244<-_start()+41
wait> time waited: 4.944027 secs p2: 'number'=0x101
p3: 'tries'=0x0
2.> time waited: 0.104395 secs p2: 'number'=0x101
p3: 'tries'=0x0
3.> time waited: 0.079024 secs p2: 'number'=0x101
p3: 'tries'=0x0
}
and> {
instance: 1 (crm.crm1)
os> p2: 'number'=0x115
p3: 'tries'=0x0
time> current sql: <none>
short> time waited: 5.627769 secs p2: 'number'=0x101
p3: 'tries'=0x0
2.> time waited: 0.465190 secs p2: 'number'=0x101
p3: 'tries'=0x0
3.> time waited: 0.082002 secs p2: 'number'=0x101
p3: 'tries'=0x0
}
从DUMP信息看来，这次的情况跟上次类似，大量的latch: shared pool等待。
客户的DB配置情况：
物理内存24G，而MEMORY_TARGET设置为22G，感觉配置的非常不合理，客户的情况跟我之前处理过的一个CASE很像（ORA-609：疑似MEMORY_TARGET设置过大导致的宕机http://blog.csdn.net/zhou1862324/article/details/17288103），都是MEMORY_TARGET参数设置过大导致出现SWAP PAGE IN/OUT的情况，最终导致数据库HANG住或宕机。
之前的CASE发生在另一位客户的一套非常重要的生产库上，数据库屡次宕机客户苦不堪言，而客户接收了我的建议将MEMORY_TARGET调低到一个合理的值之后，类似的问题没有再发生了。
所以，对于这个案例，我给了客户2个建议：
1.减少 memory_target 和 memory_max_target，预留更多内存供OS使用，减少发生SWAP PAGE IN/OUT的可能性。
2.启用hugepages，hugepages本身就是锁定在内存中不能被SWAP的，但Hugepages与memory_target不兼容，所以需要禁用memory_target，设置sga_target和pga_aggregate_target。
关于HUGEPAGE，可以参考我转的一篇文章HugePages on Oracle Linux 64-bit（http://blog.csdn.net/zhou1862324/article/details/17540277）。
解决方法：
最终客户选择了调小memory_target 和 memory_max_target，问题未再出现。
现象：
2节点RAC，数据库忽然HANG住，重启一个实例后恢复正常。
分析：
故障时间段约为8:30-10:00，以下为alert报错：
alert_crm2.log：
Mon May 27 06:54:26 2013
SUCCESS:> Mon May 27 07:32:24 2013
Thread 2> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] []
ORA-03135: 连接失去联系
Mon May 27 09:54:56 2013
Errors> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] []
ORA-03135: 连接失去联系
Mon May 27 09:54:56 2013
Errors> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] []
ORA-03135: 连接失去联系
Mon May 27 09:54:56 2013
Errors> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] []
ORA-03135: 连接失去联系
Incident> USER (ospid: 15258): terminating the instance
Mon May 27 09:55:05 2013
ORA-1092 :> ORA-00600: internal error code, arguments: [723], [109464], [127072], [memory leak], [], [], [], [] <-memory leak?
Incident> loadavg : 69.72 40.04 27.44
memory> swap info: free = 0.00M alloc = 0.00M total = 0.00M
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
0 S> #0 0x0000003e2d6d50e7 in semop () from /lib64/libc.so.6
#1 0x000000000778a4f6> #7 0x0000000003b87b4a in kjdrchkdrm ()
#8 0x0000000003a38c5a>
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 6261 27-May-13 09:00:40 404 7.5
End Snap: 6262 27-May-13 10:00:34 488 5.3
Elapsed: 59.90 (mins)
DB Time: 10,417.13 (mins)
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms)> gc current block 2-way 411,847 673 2 3.8 Cluster
gc>
*** 2013-05-27 07:26:41.101
Trace> (session) sid: 1645 ser: 1 trans: (nil), creator: 0x590fc76e0
flags: (0x51) USR/-> Dumping Session Wait History:
0:> wait_id=348204630 seq_num=17176 snap_id=1
wait> wait times (usecs) - max=infinite
wait> occurred after 228 microseconds of elapsed time
1:>
CRMM01_130527_0800.nmon.xlsx:
CPU Total CRMM01 User% Sys% Wait% Idle% CPU% CPUs
9:38:00 2.4 0.8 6.2 90.7 3.2 24
9:39:31 1.3 1 5.9 91.9 2.3 24
9:41:01 16 5 7.6 71.4 21 24
9:42:33 91.3 7.9 0.2 0.6 99.2 24 <===== CPU 99.2%Busy (When> Time PID %CPU %Usr %Sys Size ResSet ResText ResData ShdLib MinorFault MajorFault Command
8:07:34 773 0.76 0 0.76 0 0 0 0 0 0 0> 8:07:34 774 36.91 0 36.91 0 0 0 0 0 0 0 kswapd1 1.54 0
Memory MB CRMM01>
Paging> Node1: swap increased after 8:00.
CRMM01_130527_0800.nmon.xlsx:
Paging> 8:03:03 589 10.81 kswapd0
8:06:03 589 1.68>
通过以上的日志分析，大致发现客户的DB在故障时间段存在一些问题：
1.内存资源紧张（a.lmd0在进行一些内存释放的操作;b.free> 2.空闲SWAP页面紧张，大量的page in/out <==引发SWAP的原因是什么？什么进程占用内存导致SWAP？是不是有memory leak的现象？
3.严重的shared> 4.实例1的lmd0在9:42-9:44HANG住（STALL）， <==== 是否跟latch获取有关？
还未完全理清的时候，客户的DB又出现了HANG住的情况，这次客户做了systemstate> HANG ANALYSIS:
instances (db_name.oracle_sid):>
Chains> Chain 1 Signature Hash: 0xb52ba8a9
[b] Chain 2 Signature: 'latch:> Chain 2 Signature Hash: 0x985d217a
[c] Chain 3 Signature: 'latch:> Chain 3 Signature Hash: 0xb52ba8a9
Chain 1:
-------------------------------------------------------------------------------
Oracle> p2: 'number'=0x101
p3: 'tries'=0x0
time> short stack: <-ksedsts()+315<-ksdxfstk()+32<-ksdxcb()+1764<-sspuser()+112<-__restore_rt()<-semop()+7<-sskgpwwait()+980<-skgpwwait()+135<-kslges()+1163<-kslgetl()+556<-kksCheckToFreeCursorStat()+336<-kksLoadChild()+8989<-kxsGetRuntimeLock()+1794<-kksfbc()+6536<-kkspsc0()+2601<-kksParseCursor()+147<-opiosq0()+1827<-kpooprx()+350<-kpoal8()+908<-opiodr()+1178<-ttcpip()+1211<-opitsk()+1455<-opiino()+1026<-opiodr()+1178<-opidrv()+580<-sou2o()+90<-opimai_real()+145<-ssthrdmain()+177<-main()+215<-__libc_start_main()+244<-_start()+41
wait> time waited: 4.944027 secs p2: 'number'=0x101
p3: 'tries'=0x0
2.> time waited: 0.104395 secs p2: 'number'=0x101
p3: 'tries'=0x0
3.> time waited: 0.079024 secs p2: 'number'=0x101
p3: 'tries'=0x0
}
and> {
instance: 1 (crm.crm1)
os> p2: 'number'=0x115
p3: 'tries'=0x0
time> current sql: <none>
short> time waited: 5.627769 secs p2: 'number'=0x101
p3: 'tries'=0x0
2.> time waited: 0.465190 secs p2: 'number'=0x101
p3: 'tries'=0x0
3.> time waited: 0.082002 secs p2: 'number'=0x101
p3: 'tries'=0x0
}
从DUMP信息看来，这次的情况跟上次类似，大量的latch: shared pool等待。
客户的DB配置情况：
物理内存24G，而MEMORY_TARGET设置为22G，感觉配置的非常不合理，客户的情况跟我之前处理过的一个CASE很像（ORA-609：疑似MEMORY_TARGET设置过大导致的宕机http://blog.csdn.net/zhou1862324/article/details/17288103），都是MEMORY_TARGET参数设置过大导致出现SWAP PAGE IN/OUT的情况，最终导致数据库HANG住或宕机。
之前的CASE发生在另一位客户的一套非常重要的生产库上，数据库屡次宕机客户苦不堪言，而客户接收了我的建议将MEMORY_TARGET调低到一个合理的值之后，类似的问题没有再发生了。
所以，对于这个案例，我给了客户2个建议：
1.减少 memory_target 和 memory_max_target，预留更多内存供OS使用，减少发生SWAP PAGE IN/OUT的可能性。
2.启用hugepages，hugepages本身就是锁定在内存中不能被SWAP的，但Hugepages与memory_target不兼容，所以需要禁用memory_target，设置sga_target和pga_aggregate_target。
关于HUGEPAGE，可以参考我转的一篇文章HugePages on Oracle Linux 64-bit（http://blog.csdn.net/zhou1862324/article/details/17540277）。
解决方法：
最终客户选择了调小memory_target 和 memory_max_target，问题未再出现。
作者：zhou1862324 发表于2013-12-25 23:12:10 原文链接
阅读：143 评论：0 查看评论
相关 [内存 参数 数据库] 推荐：
VoltDB内存数据库分析
- - 淘宝核心系统团队博客VoltDB是一个宣称性能超过Mysql 100倍的新型数据库. 它源自Micheal Stonebraker一篇论文H-Store. 在这篇论文发表后，Stonebraker成立了VoltDB公司带着他的一些学生开始在OLTP数据库领域打拼. Stonebraker从上世纪70年代——数据库刚开始发展的时间——就开始在数据库领域活跃，这样的老古董提出的数据库的新想法，给了整个存储领域很大的想象空间.
MySQL 数据库性能优化之缓存参数优化
- flychen50 - Sky.Jian 朝阳的天空在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题，所以最近打算写一个MySQL数据库性能优化方面的系列文章，希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助. 这是 MySQL数据库性能优化专题 系列的第一篇文章：MySQL 数据库性能优化之缓存参数优化.
对内存数据库的使用已达临界点
- - InfoQ cn微软的David Campbell在文章《 内存数据库即将到到临界点（The coming in-memory database tipping point）》中说到， 内存数据库离广泛采用越来越近了. 他还说明了微软在这个领域的策略. 据David所说，以下各种趋势使得内存数据库会在五年内变得普遍：.
内存数据库分析-装载整理
- - 人月神话的BLOG转载整理自： http://titan.iteye.com/. 传统的数据库管理系统把所有数据都放在磁盘上进行管理，所以称做磁盘数据库（DRDB:Disk-Resident
Database）. 磁盘数据库需要频繁地访问磁盘来进行数据的操作，由于对磁盘读写数据的操作一方面要进行磁头的机械移动，另一方面受到系统调用（通常通过CPU中断完成，受到CPU时钟周期的制约）时间的影响，当数据量很大，操作频繁且复杂时，就会暴露出很多问题.
内存数据库FastDB和SQLite性能测评
- - CSDN博客数据库推荐文章在很多项目中，经常会碰到这样的需求，需要对大量数据进行快速存储、查询、删除等操作，特别是在一些针对诸如运营商、银行等大型企业的应用中，这些需求尤为常见. 比如智能网中的大量在线并发用户的数据管理、软交换平台中的在线信息交互、宽带/3G等数据网中在线用户行为记录等等. 针对这些情形，我们通常需要选择高性能的数据库产品，而且通常需要使用内存数据库，顾名思义，内存数据库指的是所有的数据访问控制都在内存中进行，这是与磁盘数据库相对而言的，磁盘数据库虽然也有一定的缓存机制，但都不能避免从外设到内存的交换，而这种交换过程对性能的损耗是致命的，目前主流数据库如SYBASE、ORACLE等都有这种缓存机制，如将特定表绑定一定的缓存，从而在一定程度上改善数据吞吐性能.
如何让NoSQL内存数据库适合企业级应用
- - CSDN博客数据库推荐文章如何让NoSQL内存数据库适合企业级应用. 作者：chszs，转载需注明. 博客主页： http://blog.csdn.net/chszs. 英文原文： How to Make Your In-memory NoSQL Datastores Enterprise-Ready. 对于每一个关注用户体验的Web应用或移动应用而言，NoSQL内存数据库（例如开源的 Redis和Memcached）正逐步成为事实上的标准.
[转]内存数据库的几个典型应用场景
- - 小鸥的博客近些年内存数据库(IMDB)技术发展迅猛. 除了与生俱来的高性能之外，IMDB本身越来越向着功能完整的独立DB的方向发展. 下面简单描述当前比较常见的几个IMDB应用场景，希望对有志于IMDB技术的同僚以启发——. IMDB最大规模的应用集中在电信领域，尤其以计费系统为主. 当然，近些年陆续开始向新的电信业务领域拓展，例如核心网、CRM、精确营销等.
围绕着内存数据库的4个流言
- - 199IT互联网数据中心作者Yiftach Shoolman是Redis Labs的联合创始人兼CTO，拥有着丰富的实践经验. Yiftach 之前曾是Crescendo Networks（后被F5收购）的总裁、创建者兼CTO，更早还是Native Networks的技术副总裁. 在本文中，Yiftach直述了当下开发者对内存数据库所存在的偏见，并提出了一些技术选型参考意见.
JVM实用参数（四）内存调优
- - Java - 编程语言 - ITeye博客理想的情况下，一个Java程序使用JVM的默认设置也可以运行得很好，所以一般来说，没有必要设置任何JVM参数. 然而，由于一些性能问题（很不幸的是，这些问题经常出现），一些相关的JVM参数知识会是我们工作中得好伙伴. 在这篇文章中，我们将介绍一些关于JVM内存管理的参数. 知道并理解这些参数，将对开发者和运维人员很有帮助.