一次系统优化！-技术人生系列-我和数据中心的故事-第十七期
你的系统中是否存在间歇性的IO性能问题，或者一直以来都IO性能不佳呢？
文章的最后，将给出共性的风险提示和检查方法，还犹豫什么呢，也查一查您的系统吧^_^。
这次我们分享的主题---看中国最美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配置做出调整！
声明：本站所有文章资源内容，如无特殊说明或标注，均为采集网络资源。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
