当我们的IO密集型的应用怀疑设备的IO抖动，比如说一段时间的wait时间过长导致性能或其他疑难问题的时候，这个现象处理起来就比较棘手，因为硬件的抖动有偶发性很难重现或者重现的代价比较高。
幸运的是systemtap可以拯救我们。从原理上讲，我们应用的IO都是通过文件系统来访问的，不管read/write/sync都是，而且我们的文件大部分都是以buffered方式打开的。在这个模式下，如果pagecache不命中的话，就需要访问设备。 知道了这个基本的原理以后，我们就可以用万能的systemtap往vfs的读写请求中受控的注入延迟，来达到这个目的。
要点有以下几个：
1. 受控的时间点。
2. 延迟时间可控。
3. 目标设备可控。
我写了个脚本注入IO延迟，模拟ssd/fio硬件的抖动来验证是否是IO抖动会给应用造成影响，三个步骤如下：
步骤1: 编译模块
| 代码如下 | 复制代码 |
|
$ cat inject_ka.stp global inject, ka_cnt
probe procfs("cnt").read { $value = sprintf("%dn", ka_cnt); } probe procfs("inject").write { inject= $value; printf("inject count %d, ka %s", ka_cnt, inject); }
probe vfs.read.return, vfs.write.return { if ($return && devname == @1 && inject == "onn") { ka_cnt++; udelay($2); } }
probe begin{ println("ik module begin:)"); }
$ stap -V Systemtap translator/driver (version 2.1/0.152, commit release-2.0-385-gab733d5) Copyright (C) 2005-2013 Red Hat, Inc. and others This is free software; see the source for copying conditions. enabled features: LIBSQLITE3 NSS BOOST_SHARED_PTR TR1_UNORDERED_MAP NLS
$ sudo stap -p4 -DMAXSKIPPED=9999 -m ik -g inject_ka.stp sda6 300 ik.ko |
|
其中参数sda6是目标设备的名字，300是希望延迟的时间，单位us（超过300很容易报错，因为通常systemtap会对脚本执行的cpu进行检查，占用过多cpu的时候会触发保护机制，导致stap抱怨退出），通常对于ssd设备是足够的。
这个步骤会生成ik.ko，请验证生成模块的机器和目标的机器，操作系统的版本是一模一样的，而且请确保你的stap版本比较高，因为udelay函数在高版本的Stap才有。
步骤2:
将ik.ko拷贝到目标机器，执行
| 代码如下 | 复制代码 |
|
$ sudo staprun ik.ko ik module begin:) |
|
步骤3:
启动应用程序开始测试后一段时间，运行如下命令开始注入：
| 代码如下 | 复制代码 |
|
$ echo on|sudo tee /proc/systemtap/ik/inject && sleep 10 && echo off|sudo tee /proc/systemtap/ik/inject |
|
其中sleep N 是希望打开注入开关的时间。
小结：systemtap用好很无敌！
祝玩得开心！