跟随LINUX的时俱进太难了

D-SMART中也根据这两个指标来分析IO问题到底出在哪，上面的这个案例是在AIX系统上的，通过分析avserv/avwait的指标，发现了可能OS层面导致了本次IO性能问题。于是自动检查相关的OS配置，包括HDISK的queue_depth，发现了这个困扰了运维人员大半年的IO性能问题：

这个诊断算法也被D-SMART应用到了LINUX上，通过iostat的数据我们可以看到：

在小型机上，avserv+avwait是IO延时，而在LINUX上avwait就已经包含了整个IO延时，这一点在开发IO诊断工具的时候就已经研究过了，于是我们就在LINUX的IO诊断工具中把AVWAIT定义为await-svctm，AVSERV=svctm。不过在分析IO的时候，总是觉得有些时候不够准确。最近在分析这些指标的时候，终于发现svctm在LINUX中已经不再反应真正的设备IO响应时间了，而是通过计算获得的数据。更恐怖的是，在LINUX 7中，如果你用man iostat查看svctm的说明，居然存在一个warning，大意是千万不要相信svctm指标，这个指标的算法存在问题，在新的sysstat工具中，svctm算法将会升级。有兴趣的朋友可以去你的linux系统上man iostat看看，老白本来想贴个图的，今天早上VPN怎么都连不上了,就不贴图了。

对LINUX上的一些指标的使用还真的是需要与时俱进的，这也是一些我们的诊断工具和运维经验知识点在小型机上都能十分精确的定位问题，而在LINUX上就经常出现一些现象与诊断不完全吻合的情况，其主要原因就是对指标的定义犯了经验主义的老毛病，因此针对LINUX的一些关键指标进行一次全面的分析势在必行。因为LINUX现在已经成为企业信息化的核心支撑平台，很多系统问题都和LINUX关系密切，故障定位于溯源不可避免的要对LINUX进行深度的分析才能完成。

就今天老白说的问题，svctm的问题导致定位IO问题是在OS层面还是设备层面出现了问题。可能有朋友会说，可以通过util来看设备使用率是否过高啊。实际上通过util来确定设备是否过于繁忙早就被认为是一个误解了。这个指标对于二十年前的设备可能还有意义，对于现在性能已经比较强大的IO设备来说，util早就已经失去参考意义了。要想确保原有的分析逻辑能够完成，我们需要通过更为复杂的手段去采集与分析iostat的数据，通过iops/avgrq-sz、await等指标的复杂计算，再参考/proc/diskstats的数据进行分析。

linux内核发展的十分快，一方面这是好事情，性能，稳定性，易管理性一直在提升，这是好事情，不过内核变化太快，工具变化太快，对于做运维工具的人来说，噩梦也是连连啊，不与时俱进，容易闹笑话。