ITPub博客

首页 > 数据库 > Oracle > 一次一波三折的节点重启问题分析-技术人生系列第二十四期-我和数据中心的故事

一次一波三折的节点重启问题分析-技术人生系列第二十四期-我和数据中心的故事

Oracle 作者:记录每一次错误 时间:2018-12-03 14:22:19 0 删除 编辑

编者注 :今天我们非常荣幸的邀请到了我们的好朋友Allen来给我们分享他的技术故事。Allen也是一名低调的高手,入行十几年,在研究ORACLE技术的过程中也是十分乐于分享;Allen在CRS/RAC的研究方面更是独树一帜,前几年写了一本书《Oracle RAC 核心技术详解》,这本书基本上是编者全面深入了解oracle RAC的指导之作,看完书作,才会发关于oracle RAC我们原来懂得太少,关于技术牛人,编者知道的也太少。不多说,先随手拍一张,就是这一本了^_^。

大家多多支持转发,我们后续会请我们的Allen在这里分享更多他的技术故事,同时我们也会邀请其他更多实战派技术大咖来参与我们的分享, 您的支持与转发是我们持续分享的动力。

前言

笔者日常的工作主要就是分析各种客户搞不定的技术疑难问题,特别是与CRS/RAC相关的;

以笔者的经验看,对于一般客户来说,分析RAC数据库节点/实例重启着实是一件非常痛苦的事。为什么这么说呢?通常,对于单个节点,单实例的数据库来说,不会存在数据库直接导致操作系统宕机的情况,而数据库宕实例的情况通常也能从alert日志中直接看出个一二三来;而对于CRS/RAC来说,就要复杂的多了,首先是概念太多,一会儿是member kill,一会儿又是node kill,一会儿又是node eviction,还有各种timeout的阈值,最后晕头转向;其次是具体现象,有时一个数据库实例重启,有时是一个数据库节点重启,更麻烦的时候是多个节点都直接重启了,最后不知所以了;最主要的还是CRS各种资源,各种进程,关系复杂,各种日志文件晦涩难读;总之,分析CRS/RAC的宕机/重启比单机来得更复杂;不过,如果你对CRS/RAC的资源组件,结构特性足够了解,你会发现其实oracle CRS总会给你留下充分的线索,帮你来最终定位问题;

今天笔者给大家分享一个数据库节点重启的问题,分析的过程一波三折,结合CRS和操作系统的相关知识点,最终得出结论;

Exadata也出问题啦

一日,客户的Exadata系统的一个计算节点发生了重启,客户觉得,exadata的性能应该非常好才是,不会出现性能问题才是,在分析了许久之后,也没有得出结论,便向我们进行求助;事实上,我们说Exadata一体机的强大,通常是指结合oracle软件的特性,优化底层硬件配置和架构,以发挥ORACLE软件和硬件设备的最大性能;然而,对于计算节点来说,其同样是ORACLE RAC的一个节点而已,如果其中配置不合理或者使用不合理,同样会造成单个或多个计算节点的宕机/重启。

CRS日志分析

既是Exadata系统,又是计算节点的重启,这正好都是笔者的强项,事不宜迟,这就开始分析啦;Exadata计算节点重启,与普通CRS的节点重启也并无多大的区别,通常来说从两个方向进行分析总没错:

  1. Oracle的集群发起的重启;

  2. 计算节点操作系统(Linux)发起的重启;

先从简单的来看,看看操作系统给我们留下了什么蛛丝马迹没有,这里我们就可以翻一翻message文件(Linux操作系统的系统日志文件):

看起来,重启不是简单的由操作系统发起的;重启的时间发生在14:26—14:30之间,除此之外,message没有提供更多信息;

操作系统没有信息,那这个锅就只能是Oracle来背了;那就先看看GI的alert日志:

可以看到CSSD的两个线程: clssnmvDiskPingThread和clssnmvWorkerThread长时间没有被调起,随后便悄无声息的重启了;

一般来说,alert日志只是对主要问题问题记录,具体细节还需要到相关进程的日志中去查看了:

然而,ocssd的日志也并没有更多信息,而且,从ocssd日志可以看到,ocssd.bin被重启前也没有node eviction的相关信息;

名词解释  

在Oracle的集群当中,节点驱逐(node eviction)是指某一个(或多个)节点和其他的节点在心跳网络上出现了通信中断,为了保证整个集群的一致性,而做出的重新启动某一个节点的行为

没有被从集群中驱逐出来,从集群的角度来讲,cssdagent 和 cssdmonitor 就可能是导致节点重启的杀手了;我们不妨来看看作为cssd的守护进程cssdagent和cssdmonitor的日志:



上面的信息就清晰明了;原来是cssdagent 进程发现了ocssd 核心进程一直没有把自己的本地心跳(LHB)信息发送给自己,所以,在LHB连续丢失27秒(misscount(30s) – reboottime(3s) =27s)之后,直接把本地节点重启了。

名词解释

本地心跳( LHB )是指 ocssd.bin   进程会每秒钟把自己的状态信息注册到 cssdagent cssdmonitor   上,以便集群了解 ocssd.bin   这个核心进程的状态信息。这种行为成为本地心跳。 Ocssd.bin   是本地心跳信息的发送者, cssdagent   cssdmonitor   是本地心跳的监控者(或者叫接受者)。


既然知道了节点是被cssdagent 重启的,而且理解了本地心跳的功能,那么重启的原因就基本上清楚了。但是ocssd.bin 进程不会无缘无故的不发送本地心跳信息,可能的原因基本有两种:

1:ocssd.bin进程出现了bug,导致本地心跳不能被发送;

2:OS层面出现了性能问题,导致了ocssd.bin 不能正常工作。

 看起来下一步又要先重新回到操作系统层面了;看看操作系统层面能否看到OS/ocssd进程的性能问题;


小提示  

Exadata 是软硬件综合一体的高性能 ORACLE 服务器,自然少不了操作系统的监控工具,它的监控工具就是 Exawatcher ;而如果是普通的服务器 / 操作系统, oracle 也提供了 oswatcher 对操作系统进行全方位、细粒度的监控,大家可以及时部署,在操作系统性能出现问题时,这些监控工具的数据对我们分析问题会非常有帮助。

操作系统分析

首先我们查看Exawatcher中的top相关输出信息,关注ocssd.bin的进程情况:

可以看到,在宕机之前的一小段时间,cssd进程的CPU利用率超过了100%,而系统正常时,CPU利用率只有1.8%左右,期间差别有点大;难道,真的是ocssd进程CPU使用率逐步上升,最后一整颗CPU都无法满足其正常运行,然后导致无法及时发送消息给monitor和agent?难道,真的又是一个bug?

 

bug的结论还是不要轻易下,cssd进程是这样,其他进程呢?操作系统整体呢?继续看下去。查看占用CPU资源最多的进程:


查看占用CPU资源最多的进程,原来ocssd.bin不是特殊的那一个,可以看到很多优先级为RT的linux内核进程CPU消耗最多;再看看CPU整体的使用情况又如何呢:


可以看到,很多CPU的使用率都已经很高了,而且sys部分的使用率非常高;这种情况,我们通常就要怀疑系统在做换入换出操作了;于是再看看当时内存的使用情况:

可以看到swap空间也已经被完全用完了!果然内存不足才是到目前为止最深的原因!


内存分析


看起来,因为内存不足而导致了CPU的使用率升高,内存使用的趋势没那么明显,我们就从CPU的使用来看看系统性能是否存在一个拐点,拐点时刻是否存在一个特别的进程占用了内存。


从CPU的使用队列来看,系统性能下降是一个渐变的过程;这样我们就取一个时间点的数据,对进程内存的使用进行分析即可;

很快,我们就找到了一个TFA进程,占用了273G的内存,分析前后可以看到该进程的内存使用量是在不断上涨的;TFA是oracle 的一个诊断信息搜集工具,看起来这里可能出现内存泄露的bug。回忆前面列出的内存信息,系统的总内存有800G左右,273G虽大,但是对整体来说,应该还可以接受;这里,我们不妨再看看Exadata计算节点的配置,果然又有所发现:

系统的hugepage 页面设置长期处于上面的情况,这意味着有(149122 *2048KB)=291GB 的内存空间被设置成为了hugepage,但是一直没有被使用。也就是说,一直有291G的内存是不能给其他应用程序(除非该应用程序可以使用hugepage, 例如:oracle的SGA)使用的,而且这部分内存还不能被swap。

结论

问题分析到了这里,我们可以发现,虽然系统有大概800G的内存,但是在问题时刻之前光TFA + hugepage free space 就消耗掉了560G左右,而且TFA还不断地要申请内存,所以就导致了系统的memory和swap基本都被耗尽,进而发生了ocssd.bin 无法发送消息给本地的cssdagent/cssdmonitor进程,导致cssdagent将节点自动重启。

我们给出的建议:

在进行了一些研究发现,旧版本的TFA在分析系统诊断信息的时候的确存在着bug,并且会导致TFA 消耗大量的物理内存。不过这个问题在最新版本的TFA中已经得到了解决,所以,只要下载并安装最新版本的TFA就可以了(或者索性暂时禁用TFA)。

另外,一般来说,hugepage的配置并不是越大越好,当配置值过大,需要使用的并不高时,大量的hugepage占用了内存空间却被白白浪费,容易引发系统性能问题;所以我们应该合理规划hugepage 的设置,减少不必要的hugepage 的占用。

本文转载于中亦安图

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31547066/viewspace-2222481/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
性格开朗,有较强的学习能力,对oracle数据库的体系结构,搭建RAC,timesten,goldengate,分布式数据库,dataguard,系统调优有较深入的了解, 尤其是oracle优化,深入学习的主机命令,对数据库的优化,SQL语句的优化有深入的认识,目前正在shell脚本,mysql,以后会有计划学习大数据和python。

注册时间:2018-07-23

  • 博文量
    171
  • 访问量
    203377