DBA小y
作者DBA小y2017-08-29 11:03
系统工程师, 中亦科技

中亦科技黄远邦技术人生(17) ——看中国最美女DBA的一次价值连城的系统优化!

字数 3302阅读 4590评论 0赞 9

这次我们分享的主题 --- 看中国最美DBA一次价值连城的系统优化!通过系统的优化,将某客户一个关键业务系统经常性卡顿和白屏的性能问题彻底解决!
首先让大家提前看一下Oracle数据库优化前后的效果比对图吧,一会再看..
优化前:
1.jpg

1.jpg

优化后:
2.jpg

2.jpg

是的,似乎有人不关心优化效果,而是关心“中国最美女DBA”。
好吧,言归正传,十七期,我们邀请到了中亦科技数据库团队的小仙女--小亦姑娘,为大家做分享上面这个价值连城的系统优化案例!之所以说价值连城,是因为对客户而言,意义重大。案例中知识点很多,精彩不断!
小亦姑娘作为中亦科技数据库团队的新生代90后DBA,成为团队中初级DBA的典型代表,本篇为其处理CASE的代表作!
注意,不要只看照片,文章才是关键!也期待小亦姑娘更多作品^_^
3.jpg

3.jpg

临危受命
"小亦,你下午和销售去解决一个潜在客户的性能问题吧。"
原来,一个保险客户,他们的核心系统,数据库是oracle单实例,跑在aix小机上。
业务系统每天都会经常性地出现卡顿和白屏现象,业务部门多次投诉了,现在客户的运维部门压力很大,如果问题继续下去,所有人都会被逼疯的。
这次他们的运维经理,找到中亦科技,希望我们可以出手解决这个问题,问题只要解决了,一切好说。之前找过一些公司,但均未能解决。问题也已经很长时间了。
看上去,客户遇到麻烦了…我,尽力吧!
问题很严重啊
到达客户现场,客户和我简单介绍了下这个系统的情况后,我就迫不及待的取出awr报告!Oracle之所以经久不衰,被客户喜爱,很重要的一个原因是可度量和可调整。
通过OWI就可以轻松了解到系统是否存在瓶颈,无数的接口等着你来控制它。
直接上等待事件,如下所示:
4.jpg

4.jpg

这一看,直接吓了一跳。数据库中这么多异常的等待,怪不得业务系统卡顿了。
可以看到:
Ø 等待事件中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:
5.jpg

5.jpg

可以看到:
在线日志写入延时最高超过137秒,最后一条记录显示,写入18K,居然需要65秒!真是让人吃惊的结果。这里不得不怀疑存储IO子系统出现了问题!难道这么简单就被小亦解决了? 嘿嘿…
令人失望的沟通
小亦将上述发现和分析方向告诉了客户,结果发现,客户对此并不意外。
听客户说到,之前找到的专业公司也发现了这个问题,然后把问题就甩给他们了,说是IO有性能问题!但是我们多次检查存储阵列、SAN交换机、链路,结果没有任何报错和有用的线索!操作系统也没有任何报错!“如果你们最后也是这个结论,那你们可以回去了!”
有点委屈,中亦又不是只做数据库服务的公司,我们是一站式服务商。小亦一定要证明给他看,我们是不一样的!
错怪了客户
难道是客户水准不够,查不出来存储IO子系统方面的问题?
正犹豫,要不要申请公司的AIX专家和存储专家过来一起排查的时候呢,不如先自己检查检查,等确认存储确实有性能问题后再说吧。
敲下iostat,结果如下所示:
6.jpg

6.jpg

看到这些数据,看来小亦真的错怪客户了!
从操作系统看LUN一级的性能表现,是非常棒的!
服务队列没有满,没有timeout和fail,读写的平均服务时间avgsrv以及最大响应时间maxserv都是非常小的。如果iostat或者sar –d没有性能问题,那么还去找存储阵列查,方向就是错的了!
思考时刻
到这里,读者可以停下来思考一下,如果是你,你会怎么接着往下查,你的怀疑方向有是什么呢?
找到通往天堂的路口
既然lgwr进程写的慢,那么小亦就用truss来获取该进程的系统调用情况吧,如下所示:
7.jpg

7.jpg

可以看到:
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不足的情况:
8.jpg

8.jpg

可以看到:
1秒内,最大的异步IO的请求数量都超过2000了,远远超过AIO设置的最大值220,IO写的慢就是必然的了。
解决方案
有了前面的分析,解决起来就简单了!
这个性能问题,我们不调SQL,我们不改数据库参数,我们改操作系统参数!
在征求公司AIX专家和团队三线专家的意见后,小亦给客户提出了以下优化方案:
修改AIO相关参数:将maxserver调大到800,同时修改maxreqs为16384
令人振奋的优化效果
做完操作系统参数调整后,小亦也是无比期待啊,就像自己的孩子一样。
第二天迫不及待给客户去了电话,“截止目前,没有再出现任何系统卡顿和白屏的情况了,实在是太感谢了!这是一次价值连城的优化啊!对业务的健康发展意义重大!你们继续做进一步的优化,商务的事情交给我!”
优化前:
9.jpg

9.jpg

优化后:
10.jpg

10.jpg

经验提示
在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配置做出调整!
11.jpg

11.jpg

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

9

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广