一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

分享预告

你的系统中是否存在间歇性的 IO 性能问题,或者一直以来都 IO 性能不佳呢?

创新互联建站专注于企业全网整合营销推广、网站重做改版、东城网站定制设计、自适应品牌网站建设、HTML5建站成都做商城网站、集团公司官网建设、成都外贸网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为东城等各大城市提供网站开发制作服务。

文章的最后,将给出共性的风险提示和检查方法,还犹豫什么呢,也查一查您的系统吧^_^。

这次我们分享的主题   ---   看中国最美 DBA 一次价值连城的系统优化!

通过系统的优化,将某客户一个关键业务系统经常性卡顿和白屏的性能问题彻底解决 !

首先让大家提前看一下 Oracle 数据库优化前后的效果比对图吧,一会再看 ..

优化前:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

优化后:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

是的,似乎有人不关心优化效果,而是关心“中国最美女 DBA” 。

好吧,言归正传,十七期,我们邀请到了中亦科技数据库团队的小仙女 -- 小亦姑娘,为大家做分享上面这个价值连城的系统优化案例!之所以说价值连城,是因为对客户而言,意义重大。案例中知识点很多,精彩不断!

 

小亦姑娘作为中亦科技数据库团队的新生代90后DBA,成为团队中初级DBA的典型代表,本篇为其处理CASE的代表作!

注意,不要只看照片,文章才是关键!也期待小亦姑娘更多作品^_^

喜欢就转发吧,您的转发是我们持续分享的动力!

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

临危受命

"小亦 , 你下午和销售去解决一个潜在客户的性能问题吧。"

原来,一个保险客户,他们的核心系统,数据库是 oracle单实例,跑在aix小机上。

业务系统每天都会经常性地出现卡顿和白屏现象,业务部门多次投诉了,现在客户的运维部门压力很大,如果问题继续下去,所有人都会被逼疯的。

这次他们的运维经理,找到中亦科技,希望我们可以出手解决这个问题,问题只要解决了,一切好说。之前找过一些公司,但均未能解决。问题也已经很长时间了。

看上去,客户遇到麻烦了 … 我,尽力吧!


问题很严重啊

到达客户现场,客户和我简单介绍了下这个系统的情况后,我就迫不及待的取出 awr 报告! Oracle 之所以经久不衰,被客户喜爱,很重要的一个原因是可度量和可调整。

通过 OWI 就可以轻松了解到系统是否存在瓶颈,无数的接口等着你来控制它。

直接上等待事件,如下所示:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

这一看,直接吓了一跳。数据库中这么多异常的等待,怪不得业务系统卡顿了。

可以看到:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

Ø     等待事件中 Log File Sync 平均每次 94ms ,占整个 DB Time 的 42% ;

Ø     log buffer space 平均每次 952ms ,占整个 DB Time 的 20% 。

Ø     ORACLE 卡住的原因是   logfile 写不下去,导致整个数据的 commit 变慢。

Ø    logbuffer space 和 buffer busy waits 显然是   Log File Sync 慢的一个附属结果。

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

显然因为 lgwr 写的慢,导致 log buffer 来不及刷到磁盘,导致 log buffer 看上去出现“满”了,其他进程不得不等待" log buffer space”, 根本原因在于 log writer 写的慢!

LGWR有多慢

接下来,小亦检查了下 lgwr 进程的 trace:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

可以看到

在线日志写入延时最高超过 137 秒,最后一条记录显示,写入 18K ,居然需要 65 秒!真是让人吃惊的结果。这里不得不怀疑存储 IO 子系统出现了问题!难道这么简单就被小亦解决了 ?  嘿嘿 …

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

令人失望的沟通

小亦将上述发现和分析方向告诉了客户,结果发现,客户对此并不意外。

听客户说到,之前找到的专业公司也发现了这个问题,然后把问题就甩给他们了,说是IO有性能问题!但是我们多次检查存储阵列、SAN交换机、链路,结果没有任何报错和有用的线索!操作系统也没有任何报错!“如果你们最后也是这个结论,那你们可以回去了!”

有点委屈,中亦又不是只做数据库服务的公司,我们是一站式服务商。小亦一定要证明给他看,我们是不一样的!

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

错怪了客户

难道是客户水准不够,查不出来存储IO子系统方面的问题?

正犹豫,要不要申请公司的AIX专家和存储专家过来一起排查的时候呢, 不如先自己检查检查,等确认存储确实有性能问题后再说吧。

敲下iostat,结果如下所示:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

看到这些数据,看来小亦真的错怪客户了!

从操作系统看 LUN 一级的性能表现,是非常棒的!

服务队列没有满,没有 timeout 和 fail, 读写的平均服务时间 avgsrv 以及最大响应时间 maxserv 都是非常小的。如果 iostat 或者 sar –d 没有性能问题,那么还去找存储阵列查,方向就是错的了!

思考时刻 
一次系统优化!-技术人生系列-我和数据中心的故事-第十七期
到这里,读者可以停下来思考一下,如果是你,你会怎么接着往下查,你的怀疑方向有是什么呢?

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

找到通往天堂的路口

既然lgwr进程写的慢,那么小亦就用truss来获取该进程的系统调用情况吧,如下所示:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

可以看到:

lgwr 大量地调用 aio_nwait_timeout,listio64 两个系统 call ,并且在 listio64 这个 call 调用之后,都会有一段时间的停顿。显然,这两个属于 AIX 系统异步 IO 的调用。

那么接下来检查异步 IO 的配置就顺其自然了。检查如下:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

# ioo -F -a|grep aio

aio_active = 1

aio_maxreqs =4096   # 最大请求数

aio_maxservers = 10     # 每个 cpu 的 aio 的最大服务数

aio_minservers = 3      # 每个 cpu 的 aio 的最小服务数

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

    该系统配置了22 CPU,每颗CPU 最多支持10个AIO SERVER,那么整个系统理论上最大是22*10=220个AIO SERVER.

继续乘胜追击,看看操作系统起了多少个AIO SERVER呢?

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

# pstat –a |grep -c kproc

320

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

可以看到,一共起了 320 个!不只是最大的 220. 看来,当最大 SERVER 不够的时候,系统是允许有突破这个限制的!

小亦之后多次持续的检查,发现都是 320 个,正常而言, AIOSERVER 过了一个空闲时间,数量将会降下去,除非一直在工作!

这就对了!小亦看到这,心里已经乐开花了,顾不得女孩子的矜持了。

AIOSERVER 不足,导致 LGWR 没有无用的 AIO SERVER,IO 压根传递不到 LUN 一级,因此 IO 长时间无法完成。

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

原因总结

可以认为是应用发出太多的 IO 请求,导致操作系统 AIO server 不能满足需求,从而导致 LGWR 写入变得极其缓慢。


再次思考 
一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

至此,读者朋友们,不妨停下来,思考下,如果是您来决策,您会怎么调整?Maxserver从10调整到多大呢?20?50?还是……

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

您的决策可能会影响到优化的效果,效果不好,可能就会影响到客户的信息,毕竟这是客户的关键业务系统啊,不妨停下来,看看小亦的选择。

选择前的确认

为了进一步坐实证据,小亦发出下列命令,获得异步 IO 不足的情况:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

可以看到:

1 秒内,最大的异步 IO 的请求数量都超过 2000 了,远远超过 AIO 设置的最大值 220 , IO 写的慢就是必然的了。

解决方案


有了前面的分析,解决起来就简单了!

这个性能问题,我们不调 SQL ,我们不改数据库参数,我们改操作系统参数!

在征求公司 AIX 专家和团队三线专家的意见后,小亦给客户提出了以下优化方案:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

修改 AIO 相关参数: 将 maxserver 调大到 800 ,同时修改 maxreqs 为 16384

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

令人振奋的优化效果

做完操作系统参数调整后,小亦也是无比期待啊,就像自己的孩子一样。

第二天迫不及待给客户去了电话,“截止目前,没有再出现任何系统卡顿和白屏的情况了,实在是太感谢了!这是一次价值连城的优化啊!对业务的健康发展意义重大!你们继续做进一步的优化,商务的事情交给我 ! ”

优化前:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

优化后:

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

经验提示

在AIX操作系统上, 如果采用文件系统存放数据库文件 ,不正确的异步IO配置,会导致IO 出现严重的性能问题。 很多客户忽略掉了这一点,并且有可能在持续忍受着糟糕的IO性能而无从下手。

中亦科技建议大家通过下列命令检查或者监控起来, 及时作出调整,确保系统运行在最佳性能状态下;

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

步骤 1-- 获取 CPU 个数

# vmstat 

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期
一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

步骤2—查看异步IO的配置

# ioo -F -a|grep aio

aio_active = 1

aio_maxreqs =4096   # 最大请求数

aio_maxservers = 10     # 每个 cpu 的 aio 的最大服务数

aio_minservers = 3      # 每个 cpu 的 aio 的最小服务数

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期
一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

步骤3—查看异步IO的maxgc:

如果maxgc长时间处于超过CPU个数*aio_maxservers的状态,则说明IO可能有严重性能问题,需要对异步IO配置做出调整!

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期

一次系统优化!-技术人生系列-我和数据中心的故事-第十七期


当前标题:一次系统优化!-技术人生系列-我和数据中心的故事-第十七期
路径分享:http://azwzsj.com/article/pgdedo.html