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

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

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

看上去，客户遇到麻烦了 … 我，尽力吧！

到达客户现场，客户和我简单介绍了下这个系统的情况后，我就迫不及待的取出 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 进程的 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 写入变得极其缓慢。

选择前的确认

解决方案

令人振奋的优化效果

在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配置做出调整！