http://blog.yufeng.info/archives/2935
当我们的IO密集型的应用怀疑设备的IO抖动,比如说一段时间的wait时间过长导致性能或其他疑难问题的时候,这个现象处理起来就比较棘手,因为硬件的抖动有偶发性很难重现或者重现的代价比较高。
幸运的是systemtap可以拯救我们。从原理上讲,我们应用的IO都是通过文件系统来访问的,不管read/write/sync都是,而且我们的文件大部分都是以buffered方式打开的。在这个模式下,如果pagecache不命中的话,就需要访问设备。 知道了这个基本的原理以后,我们就可以用万能的systemtap往vfs的读写请求中受控的注入延迟,来达到这个目的。
要点有以下几个:
1. 受控的时间点。
2. 延迟时间可控。
3. 目标设备可控。
我写了个脚本注入IO延迟,模拟ssd/fio硬件的抖动来验证是否是IO抖动会给应用造成影响,三个步骤如下:
步骤1: 编译模块
probe procfs( "cnt" ). read { |
$value = sprintf( "%d\n" , ka_cnt); |
probe procfs( "inject" ).write { |
printf ( "inject count %d, ka %s" , ka_cnt, inject); |
println( "ik module begin:)" ); |
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 |
其中参数sda6是目标设备的名字,300是希望延迟的时间,单位us(超过300很容易报错,因为通常systemtap会对脚本执行的cpu进行检查,占用过多cpu的时候会触发保护机制,导致stap抱怨退出),通常对于ssd设备是足够的。
这个步骤会生成ik.ko,请验证生成模块的机器和目标的机器,操作系统的版本是一模一样的,而且请确保你的stap版本比较高,因为udelay函数在高版本的Stap才有。
步骤2:
将ik.ko拷贝到目标机器,执行
步骤3:
启动应用程序开始测试后一段时间,运行如下命令开始注入:
$ echo on| sudo tee /proc/systemtap/ik/inject && sleep 10 && echo off| sudo tee /proc/systemtap/ik/inject |
其中sleep N 是希望打开注入开关的时间。
小结:systemtap用好很无敌!
祝玩得开心!