资源供给：IO子系统之四

     简单案例描述1： 某新华书店综合业务系统的存储系统从HP VA7100升级到HP EVA 8000之后，业务系统性能没有得到提高，甚至还略有下跌，最不爽的是sar -d显示磁盘利用率很高。而从sar -d的tps远远未达到磁盘本身的iops，hp认为可能是虚拟化存储用了过多的空间导致，在释放一部分空间之后依然表现如此。我们综合判断，应该未有足够的IO压力到达磁盘，应该是从主机到磁盘的某个通路的队列被塞满导致的，多路径软件有助于EVA 8000整体性能的提高，在部署了多路径软件之后，EVA 8000的存储性能明显得到提高，吞吐量加大，磁盘利用率下跌。
   
    简单案例描述2：某运营商的CRM、账务、计费系统突然运营性能表现变差，AWR显示IO性能下跌，每次IO的响应速度达到40多ms，甚至100ms，三个系统同时变差，同时系统负载并没有发生明显的变化。判断应该是IO子系统的共同通路发生了故障，从主机检查发现每台主机有一个FC卡发生故障，经最终确认，一台SAN交换机发生故障，剩余一台SAN交换机不足以支撑业务系统，从而导致IO子系统吞吐量急剧降低。

   简单案例描述3：某运营商的计费系统突然运行极为缓慢，IO响应速度奇慢无比，操作系统显示100%的利用率，同时tps几乎为零，显然IO子系统出现了问题。经检查是由于网络密集短时间中断（秒甚至压秒级别中断频繁发生），导致EMC SRDF容灾无法同步到远程，导致写IO始终无法完成，导致IO挂起。为什么会出现IO利用率100%，同时tps为0，原因很简单，由于无法完成写操作，导致磁盘系统队列被填满，最终磁盘系统挂起。

   简单案例描述4： 某运营商的DataGuard standby系统，IO吞吐量始终无法让人满意，磁盘系统的串行测试效能良好，主要是无法提供高压力的并行，简单通过增加缺省的磁盘队列长度为1到64，磁盘的并行吞吐量大幅度上升，完成并行恢复的目标。

  以上的例子以及前面所有关于Io的描述都为了揭示一个道理：
        当IO吞吐量在正常范畴之内，IO响应延迟快速攀升，几乎可以肯定为以下两个原因：（1）、配置不当 （2）、IO子系统故障。遇到这种问题，大量的DBA会进行所谓的SQL优化，劳而无功。而所谓的配置不当，尤其在大家看到磁盘利用率很高，但是tps不够高的情况几乎基本上由队列不够引起，也就是无法使更多的业务压力到达IO子系统。当然这个队列不足可能会发生在IO链路的各个部位：HBA，SAN Switch, LVM, Filesystem, Disk Array Control, Disk。
      而多路径软件事实上是一种更好的队列平衡方式，多路径软件在RAID 1环境下会很大程度的提高磁盘子系统的IO吞吐量。

     在前面的IO子系统描述中还存在一种情况：
     IO吞吐量超过限制值，IO响应延迟快速升高。基于IO子系统的吞吐量曲线特征，这个时候就需要降低磁盘系统IO量，可以通过内存换IO或者通过SQL优化降低IO开销。

    另外的情况：
   IO响应延迟正常，IO响应延迟正常意味着IO系统工作正常，至少表示IO子系统在配置和工作上不存在问题。

    再次回到吞吐量曲线，熟悉这个吞吐量曲线，所有关于IO的性能调整就都解决了。
  

     衡量磁盘子系统的基本指标：
   
    磁盘利用率
    磁盘队列
    tps
    avwait
    avserv

   磁盘利用率的高低一般没有太大的问题，只要该磁盘利用率充分反映可应有的tps就可以了。我们判断的一个基本因素为：只要tps在合理的范围之内，avwait和avserv必须具有良好的延迟响应，如果无法匹配，则意味着IO子系统出现问题，需要进行调整。这个时候主要通过查看各级IO子系统吞吐量和队列统计来完成。一般来说，在正常工作的情况下，只要保持足够长的队列以及前后组件之间的IO压力相互匹配即可。


   

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-777027/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/92650/viewspace-777027/