【医院信息系统典型故障案例解析】磁盘条带化及队列深度参数调优

【案例概述】

案例关键字：AIX；条带化；队列深度；参数调优

系统的底层设计十分重要，很多IT系统建设项目往往只关注项目上层应用开发及上线而忽略了系统底层的规划与设计，如底层存储架构设计及参数设置的合理性，这将直接影响上层应用IO性能而导致不可逆的应用瓶颈，往往需要推倒系统后重来才能根本解决问题，下面我们用一个案例来简要说明一下。

【案例还原】

小L是某医院资深运维工程师，最近他正在为他所在医院的某个新上线的系统“捉急”。该系统最近应用一直报卡、慢，特别是业务高峰期，应用反应特别慢，某些操作可能要数十秒乃至分钟级才能有反馈，极大影响了业务。经过查询分析后发现，该系统的磁盘IO持续为100%，那为什么IO会如此高？让我们深入剖析一下。

该院该系统使用的操作系统是AIX 6.1，配套的存储是XIV，该系统从XIV分配了4个lun ，AIX操作系统识别为hdisk2、hdisk3、hdisk4、hdisk5，并将这4块hdisk一起分配给了一个oradata的vg，而这个vg分配了lv_data的lv给数据库作为数据文件的容器，通过nmon监控发现，4块hdisk的磁盘，只有hdisk2为100%，而其它hdisk为空闲较多，那为什么磁盘工作的时候没有平衡负载呢？翻看回原来该系统的实施文档发现，当时创建lv的时候用的命令如下：

经查发现，原来创建lv的时候未加入-s的参数，未对lv进行条带化，故导致磁盘hdisk无法真正负载工作所致。而且经查询，磁盘参数的关键参数队列深度queue_depth为默认值1，详询该项目当时的实施工程师小W，得到的回复是“因为存储XIV是全局打散的，已经底层做过条带化，无需在系统层面再做条带化，故而没有加-s参数，至于磁盘队列深度参数，一般是默认的不修改”。

小L也是认死理的，经过数据库和系统的全面分析，认定肯定是lv条带化及磁盘队列深度参数设置出了问题，故而在XIV重新分配了测试的lun。小L对比了做条带化和不做条带化的IO区别以及修改队列参数值和不修改队列参数值的区别，很明显，做过条带化以及把队列深度值修改为256的IO性能有质的飞越，这也让小L更有底气。最后小L重新部署了环境，在创建lv的时候加入了-s 1M的参数对lv进行条带化，并且修改磁盘队列深度参数queue_depth为256，并在上面重新迁移数据库后，业务恢复正常。

【案例总结】

1.关键的底层架构一定要进行合理设计，一些关键底层参数可以在系统上线前进行测试,使得底层物理架构环境最优化，免去推倒重来的麻烦；

2.系统项目实施的时候，一定要留存项目实施的所有关键文档，方便在出问题的时候，对一些关键操作进行查询，保障在出问题的时刻能最快速的进行处理；

3.项目实施人员技术良莠不齐，很多实施人员的经验也不足，故在项目实施阶段，应特别关注核心流程核心操作的进展，对事关项目骨干的架构应开会讨论，集思广益，对一些产品如存储等的特点要刨根问底，避免实施过程中的想当然。