客户solaris平台上的一套11.2.0.4 RAC近日连续2次重启,原来也会重启,最近频率偏高,要求调查一下原因。
<因为现场在客户环境中做的操作,有些日志和命令输出只能找类似的放在文章中。solaris不熟,除了unix通用的命令外一无所知,很多命令在现场上网查。>
故障时间点,在/var/adm/messages中有panic, crash dump的相关信息,检查/var/crash目录下有生成dump,序号已经到了38(说明这是个老问题)。这些dump文件是压缩文件,执行savecore -f dumpfile.38后,得到vmcore.38和unix.38文件,这个和AIX KDB工作原理一样。
执行mdb -k 38调入当日的crash dump文件,::msgbuf没有超出messages的额外信息;::memstat显示大约还有30G的剩余内存,所以不像是内存耗尽;::ps看没有状态异常的进程;$c查看故障线程的堆栈,大概是类似下面的信息:
d50a2f4c genunix:kadmin+10c (5, 0, 0, db325400)
d50a2f84 genunix:uadmin+8e (5, 0, 0, d50a2fac, )
查了一下,这是手工发起crash dump的调用堆栈,类似AIX的sysdumpstart命令,进一步查::cpuinfo -v发现导致panic的进程是cssdagent(实际上可以用<kthread_t的地址>::thread子命令直接看,因为在文章的下面,没用上:-()。现在明了了,服务器的异常重启是Oracle Cluster进行fence的结果。
查看节点的cssdagent日志,没有异常信息,但是在对端节点上的群集alert文件中有下面的信息(非原始信息):
[ohasd(11243)]CRS-8011:reboot advisory message from host: racnode01, component: cssagent, with timestamp: L-2009-05-05-10:03:25.340
[ohasd(11243)]CRS-8013:reboot advisory message text: Rebooting after limit 28500 exceeded; disk timeout 27630, network timeout 28500, last heartbeat from CSSD at epoch seconds 1241543005.340, 4294967295 milliseconds ago based on invariant clock value of 93235653
这说明节点1因为心跳超时导致驱逐,上面cssdagent没有日志,可能是没有来得及写入到日志文件?
如果真的是网络方面的原因,节点2上应该也有告警,而节点1上也应该有渐进的心跳丢失提示,所以比较合理的解释是,节点1当时出现性能过载,或者个别高优先级的异常进程占据了CPU不释放,导致cluster心跳侦测线程无法获得调度执行,引发超时,包括其他写入日志文件的线程也均受到干扰无法完成执行。
- 避免这种异常情形的出现,这种高优先级的进程通常是IO相关,例如在核心层运行的磁盘驱动,客户环境比较复杂,IBM和曙光的存储并存,不排除存在驱动程序Bug或者冲突导致IO挂起、性能异常。从数据库软件层面,我们尽量避免突发的IO访问触发这种异常,建议关闭direct path read,现场我们用alter system set "_serial_direct_read"=never scope=both sid='*'动态关闭。
- 可以考虑增加心跳侦测的超时时间,让群集对隔离驱逐更迟钝一些,事后查了一下,在10.0.1 with Fix for unpublished Bug 4896338之后主要是2个参数控制:
其中对misscount/disktimeout的修改,需要停止群集的其他节点,用crsctl set css misscount|disktimeout <newvalue>进行修改。