Posts tagged systemtap

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

0

当我们的IO密集型的应用怀疑设备的IO抖动,比如说一段时间的wait时间过长导致性能或其他疑难问题的时候,这个现象处理起来就比较棘手,因为硬件的抖动有偶发性很难重现或者重现的代价比较高。

幸运的是systemtap可以拯救我们。从原理上讲,我们应用的IO都是通过文件系统来访问的,不管read/write/sync都是,而且我们的文件大部分都是以buffered方式打开的。在这个模式下,如果pagecache不命中的话,就需要访问设备。 知道了这个基本的原理以后,我们就可以用万能的systemtap往vfs的读写请求中受控的注入延迟,来达到这个目的。

要点有以下几个:
1. 受控的时间点。
2. 延迟时间可控。
3. 目标设备可控。

我写了个脚本注入IO延迟,模拟ssd/fio硬件的抖动来验证是否是IO抖动会给应用造成影响,三个步骤如下:
步骤1: 编译模块
(更多…)

Linux下如何知道文件被那个进程写

9

晚上朔海同学问:

一个文件正在被进程写 我想查看这个进程 文件一直在增大 找不到谁在写 使用lsof也没找到

这个问题挺有普遍性的,解决方法应该很多,这里我给大家提个比较直观的方法。

linux下每个文件都会在某个块设备上存放,当然也都有相应的inode, 那么透过vfs.write我们就可以知道谁在不停的写入特定的设备上的inode。
幸运的是systemtap的安装包里带了inodewatch.stp,位于/usr/local/share/doc/systemtap/examples/io目录下,就是用来用途的。
我们来看下代码:

[shell]
$ cat inodewatch.stp
#! /usr/bin/env stap

probe vfs.write, vfs.read
{
# dev and ino are defined by vfs.write and vfs.read
if (dev == MKDEV($1,$2) # major/minor device
&& ino == $3)
printf ("%s(%d) %s 0x%x/%u\n",
execname(), pid(), probefunc(), dev, ino)
}
[/shell]
这个脚本的使用方法如下: stap inodewatch.stp major minor ino

下面我们构造个场景: dd不停的写入一个文件,查出这个文件的ino, 以及它所在设备的major, minor, 运行stap脚本就可以得到答案。

(更多…)

GLIBC 2.16 支持systemtap静态检查点

4

刚@淘宝雕梁 告诉我 GLIBC 2.16 支持systemtap静态检查点,消息源在这里, 摘抄相关部分如下:

* New configure option –enable-systemtap builds SystemTap static probes
into libc for setjmp and longjmp and into libpthread for various operations.
So far the setjmp/longjmp probes and some of the libpthread probes are
provided only for i*86 and x86_64.
Implemented by Roland McGrath and Rayson Ho.

目前主要是在setjmp/longjmp和pthread相关的锁操作,而且只支持 i*86 and x86_64 平台。我们到源码验证下:
(更多…)

latencytop深度了解你的Linux系统的延迟

8

我们在系统调优或者定位问题的时候,经常会发现多线程程序的效率很低,但是又不知道问题出在哪里,就知道上下文切换很多,但是为什么上下文切换,是谁导致切换,我们就不知道了。上下文切换可以用dstat这样的工具查看,比如:
[shell]
$dstat
—-total-cpu-usage—- -dsk/total- -net/total- —paging– —system–
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
9 2 87 2 0 1|7398k 31M| 0 0 | 9.8k 11k| 16k 64k
20 4 69 3 0 4| 26M 56M| 34M 172M| 0 0 | 61k 200k
21 5 64 6 0 3| 26M 225M| 35M 175M| 0 0 | 75k 216k
21 5 66 4 0 4| 25M 119M| 34M 173M| 0 0 | 66k 207k
19 4 68 5 0 3| 23M 56M| 33M 166M| 0 0 | 60k 197k

#或者用systemtap脚本来看
$sudo stap -e ‘global cnt; probe scheduler.cpu_on {cnt< <<1;} probe timer.s(1){printf("%d\n", @count(cnt)); delete cnt;}'
217779
234141
234759
[/shell]

每秒高达200k左右的的上下文切换, 谁能告诉我发生了什么? 好吧,latencytop来救助了!

它的官网:http://www.latencytop.org/

Skipping audio, slower servers, everyone knows the symptoms of latency. But to know what’s going on in the system, what’s causing the latency, how to fix it… that’s a hard question without good answers right now.

LatencyTOP is a Linux* tool for software developers (both kernel and userspace), aimed at identifying where in the system latency is happening, and what kind of operation/action is causing the latency to happen so that the code can be changed to avoid the worst latency hiccups.

它是Intel贡献的另外一个性能查看器,还有一个是powertop,都是很不错的工具.
(更多…)

SystemTap –Linux下的万能观测工具

5

Linux下谁在切换我们的进程

5

我们在做Linux服务器的时候经常会需要知道谁在做进程切换,什么原因需要做进程切换。 因为进程切换的代价很高,我给出一个LMbench测试出来的数字:
Context switching – times in microseconds – smaller is better
————————————————————————-
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
——— ————- —— —— —— —— —— ——- ——-
my174.cm4 Linux 2.6.18- 6.1100 7.0200 6.1100 8.7400 7.7200 8.96000 9.62000

在我的很高端的服务器上,进程切换的开销在8us左右, 这个相对于高性能的服务器是不可接受的, 所以我们要在一个时间片内尽可能的多做事情,而不是把时间浪费在无谓的切换上。

好奇害死猫,我们来调查下谁在切换我们的进程:
(更多…)

Go to Top