首页 » ORACLE 9i-23c » Troubleshooting Instance crash with ORA-29770 LMS is hung on SLES-11

Troubleshooting Instance crash with ORA-29770 LMS is hung on SLES-11

  • 2018/01/19
  • ORACLE 9i-23c
  • 851 views
  • Troubleshooting Instance crash with ORA-29770 LMS is hung on SLES-11已关闭评论

Oracle RAC环境中有时常因为LMS进程取不到足够的CPU而hang,最终在lmhb监控进程发现lms hung超过70秒后而终止实例。lmhb是11G R2引入的RAC环境中新的后台进程，用于监控LMON、LMD、LMSn等RAC关键的后台进程，确认本地以上background process不被阻塞或spin， LMHB是Lock Manager HeartBeat的缩写。LMHB进程的跟踪日志也成为诊断RAC故障的主要的日志文件。

在12c后lmhb还可能会监控DBRM进程，除了ora-29770, 还有可能会提示ora-29771错误。如果发现某一个进程在一段时间之内没有相应LMHB的心跳，那么LMHB进程就会尝试找到阻塞该进程的阻塞进程。如果阻塞进程不是数据库必要的后台进程，LMHB进程就会通过终止阻塞进程的方式来解决。

下面介绍与LMHB相关的一些隐含参数。
_lm_rcvr_hang_check_frequency:整个桉树来控制LMHB检查LMON、LMS、LMD和LCK0心跳的时间间隔。默认是20s。
_lm_rcvr_hang_allow_time：这个参数用来指定LMHB能够容忍的进程hang住的最长时间。默认70s，
_lm_rcvr_hang_kill:这个参数指定LMHB进程是否可以通过kill进程的方式来解决hang的问题。默认为true。
_lm_rcvr_hang_check_system_load：这个参数指定LMHB在分析问题时是否将操作系统负载也考虑在内。默认值为True

主要收集的日志:
– Alert logs form all instances ( Cluster alert.log, Rdbms alert.log, ASM alert.log )
– ocssd.logs for all instances ( note older files are named ocssd.l01, .. )
– LMON, LMSn, LMD0 traces from all instances
– Any other traces mentioned in any alert.log
– lmhb traces ( LMHB monitors LMON, LMD, and LMSn processes to ensure they are running normally without blocking or spinning )
– CHM and OSWatcher logs from the eviction time
– OS message logs form all nodes ( /var/log/messages for Linux )

这里记录一种现象：
1, db alert log 显示ora-29770 和lms has not moved for xx sec.
2, lmhb 显示loadavg 负载高
3， top 显示lms进程占用CPU高
4， top or mpstat 显示sys cpu高
5， gc cr failure 状态值高
6， UDP error包增长
7， lms 进程显示call stack如下

__poll()+47<-ssskgxp_poll()+40<-sskgxp_select()+263<-skgxpiwait()+3680<-skgxpwaiti()+1544<-skgxpwait()+162<-ksxpwait()+2501<-ksliwat()+12852<-kslwaitctx()+1
63<-kslwait()+141<-ksxprcv_int()+6092<-ksxprcvimd()+36<-kjctr_rksxp()+313<-kjctrcv()+398<-kjcsrmg()+102<-kjmsm()+4953<-ksbrdp()+971<-opirip()+623<-opidrv()+
603<-sou2o()+103<-opimai_real()+266<-ssthrdmain()+252<-main()+201<-__libc_start_main()+230<-_start()+36

sendmsg()+16<-sskgxp_sndmsg()+444<-skgxpsegsnda()+146<-skgxpimcpy()+5195<-skgxpmcpy()+238<-ksxpmcpy_with_bcb()+1115<-kclbcpy2()+324<-kcl_snd_cur()+2376

可能的原因
因为操作系统在刷新大量的dirty pages使用了大量的sys cpu.

解决方法
调整内核参数
vm.dirty_background_ratio = 1
vm.dirty_ratio = 3

可以修改/etc/sysctl.conf 执行sysctl -p生效
或
# echo 1 > /proc/sys/vm/dirty_background_ratio
# echo 3 > /proc/sys/vm/dirty_ratio

Related Posts:

打赏

, , ,

对不起，这篇文章暂时关闭评论。

上一篇：

下一篇：