巧用Systemtap注入延迟模拟IO设备抖动

原创文章，转载请注明： 转载自系统技术非业余研究

本文链接地址: 巧用Systemtap注入延迟模拟IO设备抖动

当我们的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("%d\n", 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 == "on\n")

  {

    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用好很无敌！

祝玩得开心！

Post Footer automatically generated by wp-posturl plugin for wordpress.

Related posts:

1. 突破systemtap脚本对资源使用的限制
2. 再谈systemtap在ubuntu 10.10下的安装
3. Linux下如何知道文件被那个进程写
4. Systemtap辅助设置tcp_init_cwnd,免对操作系统打Patch
5. Linux高速缓存使用率调查

   from：http://blog.yufeng.info/archives/2935