ITPub博客

首页 > 数据库 > Oracle > 一次数据库升级引发的惊天大案-技术人生系列第二十六期-我和数据库的故事

一次数据库升级引发的惊天大案-技术人生系列第二十六期-我和数据库的故事

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

前言:

中国银行DBA团队是在中行数据中心自主化运维过程中产生的一个顶尖技术团队,团队年轻有活力,中行数据中心的系统运维时时可以看到他们的身影,发起的的技术公开课场场爆满, 技术实力在我们所见的众多客户中首屈一指,团队成长速度也是作为乙方的我们大为惊叹的;今天我们有幸邀请到甲方工程师与我们来分享他们的技术故事,大家来看看在国有大型银行做DBA会是一种怎样的体验,需要怎样的专业素养,也希望以后能邀请我们更多的客户来与我们持续分享。



涛神,浸淫oracle技术十多年,深谙oracle内核技术精髓,擅长处理oracle各项性能问题。现任中国银行数据中心首席oracle专家,对该银行几百套Oracle数据库的特征了如指掌,日常问题处理手到擒来,紧急故障又快又准,疑难杂症直命病灶,颇有大家风范。涛神的分析报告尤为精彩,抽丝剥茧,细致入微,每每被奉为中国银行高手如林的DBA小组的经典教材,也是中国银行自主化运维道路上DBA的技术领路人,正所谓,中行我涛哥,技高CASE多!今天我们就来看看涛神分析的一个典型问题。

                                                                                             --感谢支姐的简介



为了规避某套系统已知的数据库bug,我们对数据库版本进行迁移升级操作,配套的操作系统版本也进行了升级操作。然而,在升级后的第一天上线运行时,系统状态是这个样子的! 你能看到问题所在么?如果是你你会放心让系统这样运行下去吗?



可以操作系统的CPU使用率偏高,其中CPU的kernel部分使用率平均达到了60%左右,峰值达到80%;同时应用程序监控方也反馈应用运行缓慢!这样看起来我们给自己惹了麻烦,我们费尽心思将版本升上去,然而系统却因此而受到影响,这样的问题不彻查清楚不足以慰藉我们升级过程中发起的一个个变更。


1
我们做了什么

我们对系统/数据库进行了升级,具体的情况如下:

     操作系统从AIX 5.3升级到AIX 7.1;

     数据库版本从 10.2.0.5升级到 11.2.0.4;

     应用主要工作为本地登录数据库查询数据,生成报表文件;

     应用操作比较频繁,并发保持在120左右;

     在升级期间,应用的代码及调用方式,业务并发均无明显变化


 注意!问题就来了,新旧两个系统外层的变化可能会有哪些?我们来一一核查如:

1

操作系统参数配置符合基线配置

2

数据库参数配置符合基线配置

3

用户参数配置符合基线配置


通过检查我们可以确认,本次升级过程中并无特殊变化;而基线配置是在不同系统上都有使用的,并无发现明显bug。


我眉头一皱发现问题并不简单,可能需要多团队的协同作战了。负责操作系统的同事到场后,结合以往升级后出现的各种CPU使用率异常的情况,启动应急操作,对系统的进行了多次调整,具体操作如下:


1

调整CPU从共享模式到独占方式

2

打开/关闭CPU超线程设置

3

打开/关闭CPU折叠功能


然而,以上尝试仍然未能对定位问题产生帮助。看起来,猜测与试验并不是解决问题的最佳路径了,现在需要的解决问题的方向与思路;

2
DBA也来搞搞操作系统

作为经验老道的DBA,当数据库出现了严重的性能问题时,我们可能会收上一两个AWR报告来进行分析定位。然而,事实上AWR报告更多时候体现的是表层的问题,当ORACLE出现极端的性能问题时,我们通常会收集一个systemstate dump来帮助我们定位其深层的根本原因;同样,当我们面对一个操作系统出现了性能异常情况,而TOPAS/NMON等工具已经无法直接帮助我们定位分析问题的时候,我们就需要了解AIX操作系统上方便有效的”systemstate dump”工具。


3
系统分析如此方便

首先,我们使用AIX的trace工具来收集系统的整体信息:

参数说明:

-a :表示 trace 进程在后台运行

-f :在单一模式下收集

-n trace 日志中写入头信息

-T :表示缓冲区的大小

-L :写到磁盘上的 trace 输出文件的大小

sleep 10 :收集 10 秒钟的数据

trcstop 停止 trace 收集


trace收集到的RAW数据为二进制文件,需要使用trcrpt,curt等命令来转化输出成可读性的报告。 ,因为问题的核心是kernal CPU使用率高的问题, 接下来我们用curt命令来生成CPU使用情况的报告:

参数说明:

-p :输出详细的进程信息

-e :输出系统调用等的耗时信息

-s :输出系统调用的错误返回信息

-t :  数据线程信息


这样,curt.out文件就可以直接读取了;其中截取该文件中的system summary部分我们可以看到如下信息:



这里,我们可以得知,除了APPLICATION(应用层,比如上层的ORACLE进程的相关操作等)外,占用CPU最多的就是SYSCALL( 事实上,SYSCALL本身的CPU时间占比就超过了50%,比APPLICATION要多,这也就是为什么我们最初在操作系统层看到kernel CPU高的原因了 );


接下来,我们再来看看根据不同应用进程的CPU使用情况:



可以看到,TOP进程中主要占据CPU的进程有两类,一类是sqlplus进程,另一类则是oracle的服务器进程,而且非常突出地,sqlplus进程的SYSCALL时间普遍高于APPLICATION的时间,这一点不得不让人疑惑;接下来我们先继续往下看:



再以进程类型进行统计,确实可以看到,sqlplus进程的SYSCALL时间着实太多,看起来已经差不多了,我们前面可以知道应用代码中就是在数据库服务器本地高并发的调用sqlplus来连接到数据库查询数据生成报表,sqlplus也许就是那个导致CPU使用率高的罪魁祸首;不过,这里我们的操作系统分析还不能到此为止,还有更多内容可以帮我们更精确地定位问题;前面我们都看到SYSCALL占用特别高,这里生成的报告中也有SYSCALL的相关分析:


从时间占比上看,系统调用的主要函数为kfork/_exit等,这些函数是啥呢?稍有些经验的工程师都会知道,操作系统在新起一个进程的时候我们通常叫做fork一个进程,也就是给其分配相关资源让一个进程启动的意思,而exit则就是简单的退出的意思,这就意味着, 我们可以认为sqlplus在fork进程和退出时,大量的CPU时间都是SYSCALL。


        基本定位了大的方向,就是sqlplus,而且是在sqlplus启动的时候;在这个分析过程中,我们也与应用开发团队进行沟通,了解到应用代码(C程序)中确实会出现大量短连接的情况;有了这样的方向后,路也就更好走了。

4
分析进程的那“一百种”方法


虽然我不是专业的系统工程师,但好歹也是常年在各种AIX操作系统平台上处理各种问题的DBA,已经知道了sqlplus是问题原因之后,那就可以有一百种方法来定位sqlplus在启动的时候到底做了什么对整个系统有影响的坏事了。

首先使用的方法是用truss命令进行跟踪,并且是在新环境(AIX 7.1+11.2.0.4)和旧环境(AIX 5.3+10.2.0.5)中同时来执行sqlplus命令(直接连接数据库,不使用连接串走监听)进行对比, 发现新环境的sqlplus登录果然比旧环境的sqlplus登录要慢 ,慢的体现是 kopen("/oracle/app/oracle/product/11.2.0.4/dbhome_1/rdbms/mesg/ocius.msb",O_RDONLY) = 8这个步骤输出前停留的时间较长。然而,我们可以说是这个步骤消耗的时间太长吗?通过我们手动vi/cat该文件均为发现有什么异常情况,所以单个文件的open应该不是问题所在;那么我们能猜测说是因为在打开这个文件之前的操作持续时间太长,而这个动作有恰好并不在truss的跟踪范围内;而且,这里还有一个问题,我们如何来确认sqlplus登录慢到底是CPU使用率高之后的一个结果还是真的根因呢?问题萦绕在脑子里,看起来这一百种方法在此时能提供的帮助也有限了...

5
TRACE值得再分析一遍


单个跟踪看起来并没有更多帮助,想来我们收集的trace还并没有充分利用起来,我们只看了CPU的情况,我们通过CPU已经大致定位到sqlplus进程存在问题,实际上trace命令收集的系统信息中的进程信息我们还并没有分析过,这个时候我们还是得老老实实的分析进程信息;


参数说明:

-O :用于定义输出时的各个选项

-p :用于指定只对某个进程或某类程序作格式化输出


我们前面分析到SYSCALL中大量的时间是被kfork和_exit占用的,我们翻看生成的文件,也看到了大量的kfork字眼,那这里我们不妨简单的过滤一下kfork的相关记录,看看都是哪些具体的信息来帮助我们进一步定位。



可以看到,kfork调用的具体操作实际大部分都是VMM segment的creation操作和vmm_forkcopy等;VMM也就是AIX的内存管理器,VMM segment creation也就是内存段的创建了,forkcopy看起来不是特别清晰,但也能知道与内存有关;同样再过滤_exit,可以看到主要调用的是VMM page delete 这样问题看起来就清晰了,sqlplus在启动和退出时,分配内存段和销毁内存段占用了大量的CPU时间,当然这种情况我们可以认为是系统CPU高的原因,也可以怀疑系统CPU使用率高后内存分配与销毁出现了缓慢,总之,sqlplus在启动和退出时对内存段的操作值得细究

6
分析进程的“第一百零一种”方法


再一次回过头来研究sqlplus,sqlplus在启动的过程中为什么会长时间消耗在内存段的创建上,而退出时又为什么会长时间消耗在内存的销毁上呢?对于这个问题,我们首先想到的是sqlplus在启动过程中到底创建了多少个内存段,是否为内存段过多导致的,这个时候我们就需要使用AIX上强大的SVMON来帮助我们了;



首先我们看到sqlplus进程号为19464210,我们查看该进程的内存分配情况:




看到异常了吗?sqlplus程序本身分配了大量的work application stack,而这些内存段大小似乎都是0,所以从总体上来说,进程起来后,我们并不会发现其有什么异常的,而在启动时却要分配这些段,却对系统造成了压力;再对此进行统计:



4096个段 !对比旧环境,sqlplus分配的work application stack只有16个,分配这4096个段就是极大的消耗了,到这里我们就可以确认: sqlplus登录/退出过程中大量的创建与销毁内存段,是导致该系统CPU高的根本原因。

7
寻根溯源


顺着思路查到现在,我们已经知道了在新环境中sqlplus的底层操作对操作系统带来的压力,那么现在新的问题来了!为什么在新环境中sqlplus会要分配如此多的内存段呢?这个是操作系统变化的原因还是数据库变化的原因呢?于是我们开始找ORACLE相关的bug,很幸运MOS上还真有类似的问题,在oracle 11.2.0.4之前的版本里,oracle存在一个bug 12547243。


该bug描述如下: 

Oracle code to handle the RLIMIT_STACK process limit is not 64bit aware in places. If a user has thestack limit set to >=4Gb high order bits are lost from the setting.


也就是说,在11.2.0.4版本之前,当系统的limit设置stack值被设置成超过4GB大小时,oracle由于在代码中没有针对32位以上高字节位的处理,导致只解读32bit,ORACLE将sqlplus进程的stack重置为32M,引发一些问题,为了修复该bug,oracle 11.2.0.4在基础版本默认引入了该补丁,这样oracle在代码中就能解读高达64位的代码了,按64位解读的话,最高也就可达到1T了,这样看来这是11.2.0.4版本里的一个预期行为。

当然,这里还有一个问题值得我们思考,那就是在sqlplus进程启动时初始化那么多work application stack(1T)意义何在呢?通常来说,sqlplus进程本身最终占用的内存不会太高,而在启动时初始化1T的内存段显然是不必要的。这个问题我们目前还未得到想要的答案,也值得多方思考。

8
还有什么值得做


了解了上述原理之后,对于我们解决问题也就大有裨益了; 将原先规范中ORACLE用户limit的stack值由规范的-1值改为4G,之后sqlplus进程按stack值的大小来分配初始化的内存段,对应的问题也就也有了极大的缓解;

问题看起来解决了,接下来我们需要的是反思, 我们在上百套系统中使用了11.2.0.4, 对于一个官方解释为预期操作的行为,为何在其他环境中未有问题,而唯独在这套系统中出现问题呢,在这套系统上的使用有何不同,能帮我们整理出什么什么样的规范呢?思考一番之后,我们总结如下:

1

高并发/高频率的sqlplus命令使用


2


调用sqlplus进程的用户属性问题

对于第一个问题,我们可以理解的是,普通的一次使用sqlplus连接数据库,我们是感知不到内存段的分配过程中的时间消耗的,只有在高并发/高频率的sqlplus命令调用叠加下,才会出现上述的情况;而这种调用,属于业务代码中的超短连接的使用,可以考虑避免,改为一次连接,多次执行的方式;

对于第二个问题,事实上,在我们的操作系统规范中,并不是每个用户的stack设置都为-1的,针对普通的应用用户,我们设置的stack值相对不会太大,而这里应用调用用户正是oracle,也就意味着应用用户拥有stack 为-1的用户设置,这并不是我们预期的。

所以,对于长期来说,我们考虑的是调整应用代码,隔离应用用户,并基于此对生产系统进行一次摸底排查,以避免后续出现更多类似情况。

本文转载于中亦安图

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

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

注册时间:2018-07-23

  • 博文量
    182
  • 访问量
    324049