前几天有个客户的系统存在性能问题，从AWR报告上我们看到是CPU使用率过高，同时GLOBAL CACHE方面的争用比较严重。系统中的烂SQL很多，数据库中很多几十GB的大表也没有分区，总之问题很多。不过这套系统使用了闪存盘，虽然IOPS高达3-4万，不过磁盘IO的性能还可以。USER IO平均值为2毫秒左右，SYSTEM IO平均值为1毫秒左右。昨天一个研发单位的数据库专家很兴奋的告诉我，他从nmon的监控数据中找到系统性能问题的根因了，存储系统存在瓶颈，因此他组织开发人员去优化物理IO比较多的SQL语句了。当然这种SQL的优化工作肯定对系统是有益的，所以我也没拦住他。不过我觉得很纳闷，明明系统中看IO情况还可以，为什么从nmon上看到IO性能存在很大问题呢？ 
我当时觉得很奇怪，就说从数据库层面上看，似乎IO量虽然很大，不过使用SSD盘的后端SAN存储的性能还凑合，不至于让系统那么慢。不过他贴了一张NMON的图出来，看上去好像盘的IO延时都有70多毫秒。我想了半天，没想明白什么原因，OS上IO采集到的数据与数据库IO延时之间出现较大差异，往往是数据库十分空闲，操作系统IO数量极少的时候才会出现，对于如此高IO负载的系统不大可能出现如此大的偏差。因为岁数大了，眼睛老化了，因此在手机上也看不清楚。
回到办公室，我突然想起来，nmon监控操作系统好像在后台采集状态是不会采集IO延时的，只有实时监控才能看到IO延时。这套系统是Oracle 11.2.0.4，默认是安装了OSWBB的，我从TFA里找到OSW的IOSTAT看了一下，IO延时都在3毫秒左右。难道是nmon和OSW采集到的数据不同？于是在电脑上打开那张图看了看，原来他看到的60+的指标并不是IO延时，而是DISK BUSY。不过他们十分确定的认为磁盘过于繁忙，说明IO负载过高，会严重影响Oracle数据库的性能。我见过很多持此观点的DBA，nmon的DISK BUSY来判断OS的IO能力是否存在瓶颈。二十多年前，我也是采用这个方式帮用户分析操作系统IO性能的，这是因为当时对这个指标的认知存在错误。DISK BUSY，在UNIX系统中叫DISK BUSY或者DISK USAGE，在LINUX中叫util%。不同的LUNIX/UNIX版本，在计算DISK BUSY上会有些不同，不过其主要是衡量一个设备存在IO的时间所占的比例，计算方式是排除掉无任何IO的时间段，剩下的时间段除以采样时间总长度，就是DISK BUSY。这个指标的历史十分悠久，要追溯到使用DAS的三十多年前。那时候的磁盘设备IO并发能力极弱，甚至还有一些IO设备是串行设备。在那个年代，DISK BUSY能够很好地反映出IO设备的繁忙程度。其算法是在某个时间段内采样IO，如果IO数大于0，则计算为1，否则计算为0。最后采样为1的占比就是DISK BUSY的值。不同版本的操作系统具体采样和计算方式会有不同，不过大体上是这样计算的。比如我们在1秒钟内采样1000个点，每个采样点上都有1个IO，那么这个设备的IOPS是1000，DISK BUSY 是100%，不过这个IO负载对于一块SSD盘来说实际上只是毛毛雨。SAN存储与现代的SSD设备都不是串行IO设备，是并行设备。在现代存储上做采样的时候，很可能出现这种情况：采样点上，50%的点是无IO的，50%的点上可能平均每个点有50个IO，那么这个设备上的IO负载是25000，负载十分高，但是DISK BUSY 的值是50%。这样就出现了DISK BUSY比较低，实际上IO负载很高的情况了。正是因为这些年存储技术的发展，传统的DISK BUSY指标已经无法反映出存储系统的真实性能瓶颈了。因此最近这二十年，我们基本上都不用DISK BUSY来判断存储设备是否存在瓶颈了。判断存储设备IO瓶颈的最佳方法是从IOPS、IO吞吐量、IO延时这三个指标来做综合判断。当IO延时与基线数据偏差较大，比如高出5倍以上，那么很可能IO系统已经出现了瓶颈。或者说IOPS或者IO吞吐量超出后端存储设备的基线值1倍以上，就说明IO系统存在瓶颈。对于基线，有时候我们在分析问题的时候缺乏历史数据和评测数据，不太好衡量基线。我们也可以通过一些经验值做一些估算。比如说对于Oracle数据库，单块读延时在10毫秒以内，IO性能对数据库影响还可以接受，超过10毫秒则会影响较大。对于PG数据库，因为使用DOUBLE CACHE，因此操作系统IO延时低于20毫秒，基本上还可以接受，超出则需要关注。对于存储设备的IO能力，也可以做一些简单的估算，比如你的数据库使用SAN存储，后端使用了100块15000RPM 的SAS HDD盘，那么可以粗略估算一下每块盘的IOPS大约是300-400,以300计算，那么大约是30000 IOPS的能力，因为RAID 5损失掉30%，那就是21000 IOPS。如果存储的CACHE 命中率是60%，那么这个存储系统大约能够提供的IO能力是21000除以0.4，也就是52500。如果这个存储系统的负载达到80%以上就会出现较大延时，那么当数据库的IOPS达到4万以上的时候，就要关注IO性能是否存在瓶颈了。对操作系统指标的理解，是要经过大量案例的磨练，并不断的通过知识学习来完成的，而实际上我们在学习这些知识的时候，往往会看到很多过时的，甚至错误的知识。还有些知识是有时代限制的，在二三十年前可能是正确的，到今天可能就不正确了。这对于DBA来说，想要正确地识别知识的真伪，确实十分困难。不过经过大量的案例的实践，不断地积累正确的知识，DBA能力就会越来越强。只要保持学习，保持参与一线技术工作，我想DBA干到五十岁是没有问题的。我今年54了，虽然已经不常在一线工作，不过偶尔还是会参与一些一线案例的分析。我也想挑战一下，DBA这行当能不能干到60岁退休。
我当时觉得很奇怪，就说从数据库层面上看，似乎IO量虽然很大，不过使用SSD盘的后端SAN存储的性能还凑合，不至于让系统那么慢。不过他贴了一张NMON的图出来，看上去好像盘的IO延时都有70多毫秒。我想了半天，没想明白什么原因，OS上IO采集到的数据与数据库IO延时之间出现较大差异，往往是数据库十分空闲，操作系统IO数量极少的时候才会出现，对于如此高IO负载的系统不大可能出现如此大的偏差。因为岁数大了，眼睛老化了，因此在手机上也看不清楚。回到办公室，我突然想起来，nmon监控操作系统好像在后台采集状态是不会采集IO延时的，只有实时监控才能看到IO延时。这套系统是Oracle 11.2.0.4，默认是安装了OSWBB的，我从TFA里找到OSW的IOSTAT看了一下，IO延时都在3毫秒左右。难道是nmon和OSW采集到的数据不同？于是在电脑上打开那张图看了看，原来他看到的60+的指标并不是IO延时，而是DISK BUSY。不过他们十分确定的认为磁盘过于繁忙，说明IO负载过高，会严重影响Oracle数据库的性能。我见过很多持此观点的DBA，nmon的DISK BUSY来判断OS的IO能力是否存在瓶颈。二十多年前，我也是采用这个方式帮用户分析操作系统IO性能的，这是因为当时对这个指标的认知存在错误。DISK BUSY，在UNIX系统中叫DISK BUSY或者DISK USAGE，在LINUX中叫util%。不同的LUNIX/UNIX版本，在计算DISK BUSY上会有些不同，不过其主要是衡量一个设备存在IO的时间所占的比例，计算方式是排除掉无任何IO的时间段，剩下的时间段除以采样时间总长度，就是DISK BUSY。这个指标的历史十分悠久，要追溯到使用DAS的三十多年前。那时候的磁盘设备IO并发能力极弱，甚至还有一些IO设备是串行设备。在那个年代，DISK BUSY能够很好地反映出IO设备的繁忙程度。其算法是在某个时间段内采样IO，如果IO数大于0，则计算为1，否则计算为0。最后采样为1的占比就是DISK BUSY的值。不同版本的操作系统具体采样和计算方式会有不同，不过大体上是这样计算的。比如我们在1秒钟内采样1000个点，每个采样点上都有1个IO，那么这个设备的IOPS是1000，DISK BUSY 是100%，不过这个IO负载对于一块SSD盘来说实际上只是毛毛雨。SAN存储与现代的SSD设备都不是串行IO设备，是并行设备。在现代存储上做采样的时候，很可能出现这种情况：采样点上，50%的点是无IO的，50%的点上可能平均每个点有50个IO，那么这个设备上的IO负载是25000，负载十分高，但是DISK BUSY 的值是50%。这样就出现了DISK BUSY比较低，实际上IO负载很高的情况了。正是因为这些年存储技术的发展，传统的DISK BUSY指标已经无法反映出存储系统的真实性能瓶颈了。因此最近这二十年，我们基本上都不用DISK BUSY来判断存储设备是否存在瓶颈了。判断存储设备IO瓶颈的最佳方法是从IOPS、IO吞吐量、IO延时这三个指标来做综合判断。当IO延时与基线数据偏差较大，比如高出5倍以上，那么很可能IO系统已经出现了瓶颈。或者说IOPS或者IO吞吐量超出后端存储设备的基线值1倍以上，就说明IO系统存在瓶颈。对于基线，有时候我们在分析问题的时候缺乏历史数据和评测数据，不太好衡量基线。我们也可以通过一些经验值做一些估算。比如说对于Oracle数据库，单块读延时在10毫秒以内，IO性能对数据库影响还可以接受，超过10毫秒则会影响较大。对于PG数据库，因为使用DOUBLE CACHE，因此操作系统IO延时低于20毫秒，基本上还可以接受，超出则需要关注。对于存储设备的IO能力，也可以做一些简单的估算，比如你的数据库使用SAN存储，后端使用了100块15000RPM 的SAS HDD盘，那么可以粗略估算一下每块盘的IOPS大约是300-400,以300计算，那么大约是30000 IOPS的能力，因为RAID 5损失掉30%，那就是21000 IOPS。如果存储的CACHE 命中率是60%，那么这个存储系统大约能够提供的IO能力是21000除以0.4，也就是52500。如果这个存储系统的负载达到80%以上就会出现较大延时，那么当数据库的IOPS达到4万以上的时候，就要关注IO性能是否存在瓶颈了。对操作系统指标的理解，是要经过大量案例的磨练，并不断的通过知识学习来完成的，而实际上我们在学习这些知识的时候，往往会看到很多过时的，甚至错误的知识。还有些知识是有时代限制的，在二三十年前可能是正确的，到今天可能就不正确了。这对于DBA来说，想要正确地识别知识的真伪，确实十分困难。不过经过大量的案例的实践，不断地积累正确的知识，DBA能力就会越来越强。只要保持学习，保持参与一线技术工作，我想DBA干到五十岁是没有问题的。我今年54了，虽然已经不常在一线工作，不过偶尔还是会参与一些一线案例的分析。我也想挑战一下，DBA这行当能不能干到60岁退休。