分享预告
你的系统中是否存在间歇性的
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配置做出调整！
分享名称：一次系统优化！-技术人生系列-我和数据中心的故事-第十七期-创新互联
网站地址：
http://www.cdkjz.cn/article/diijcj.html
