该系列前面的帖子:
OpenSolaris新特性解析之一:Opensolaris之前身今世
OpenSolaris新特性解析之二:ZFS
OpenSolaris新特性解析之三:SMF
OpenSolaris新特性解析之四:FMA
这个系列的第五篇文章准备介绍下dtrace，因为dtrace这个东东比较复杂一点，所以要分成几个部分写，放在一篇文章里面工作量太大了。这篇将介绍dtrace的基础知识。
dtrace是solaris上面的一个调试工具，对于我们解决系统问题，分析系统性能，调试程序有着很大的帮助。因为dtrace几乎可以探测到系统的
每一个部分，包括应用程序和内核，有了这个工具整个系统的活动对于我们而言将变得透明和可见，所以对于我们理解系统的行为，发现问题的作用相当大。以前需
要几个星期才能解决的问题，用dtrace可能几天甚至几个小时就能够解决。
对于调试程序部分，我们以前如果需要调试一个程序，首先是要修改程序的源代码，然后再编译，最后再执行去发现问题，而有了dtrace，我们可以省去这些
步骤，写一段dtrace的脚本就能够完成这个工作。比如你怀疑传递给系统调用 read 的参数 fd
出了问题，想把它打印出来，你需要做的是：首先得到一份内核源码，找到 sys_read() 的函数体中插入 printk()
语句，接下来重新编译内核，然后用新的内核重新启动系统。谢天谢地，你总算看到了你想要看到的东西，不过你马上会发现遇到了一个新的麻烦：除非重新启动系
统到原来的内核，printk()
会无休止地打印下去。而有了dtrace这个调试只需要一个几行的dtrace脚本就可以完成，不需要修改内核原代码，不需要重新编译和重起。另外支持的
调试语言和产品也很多,比如Java, C++,Perl, Php, Python, Ruby on Rails, MySQL, and
PostgreSQL
先让我们切换到root,然后在终端里面输入dtrace -l，大家可以看到类似下面的输出：
4271 fbt sdbc sd_iob_dcb2695 entry
4272 fbt sdbc sd_iob_dcb2695 return
4273 fbt sdbc sd_iob_dcb2696 entry
4274 fbt sdbc sd_iob_dcb2696 return
这里的每一行就是dtrace的探测点，dtrace的主要工作就是依靠这些探测点来完成的。4274这样的数字是这个探测点在系统内部的ID，
fbt:： sdbc ：sd_iob_dcb2696：
return这个四元组构成了这个探测点的名字，fbt是这个探测点的内核提供者，sdbc是模块的名字,
sd_iob_dcb2696是函数的名字，return表明这个探测点是放在sd_iob_dcb2696这个函数返回的时候。
是不是感觉有点晕，这些东东到底是干什么用的？我们还是先看个列子。先运行下mpstat，得到类似下面的输出:
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 40 0 21 658 223 750 48 87 17 0 4399 4 6 0 90
1 41 0 8 307 36 819 66 87 18 0 4371 4 5 0 91
其中有一列是xcal,这个表明了处理机间的调用 ，这样的调用是很花时间的，如果你发现自己的电脑上输出了xcal特别高，至少这个东西是你系统性能的瓶颈之一。我们希望能够知道到底是哪个程序造成了这么高的xcal,用dtrace很容易就可以做到这一点。
建立一个文件，拷贝下面的内容进去，然后保存为xcal.d。
#!/usr/sbin/dtrace -s
sysinfo::
calls
{
@name[execname] = count();
}
然后执行dtrace -s xcal.d，等一段时间后，按ctrl+c，可以看到类似下面的输出:
dtrace 29
intrd 34
sched 1798
可以造成xcall的程序的名字和各自的次数，比如我的电脑上sched造成了1798次xcall。
#!/usr/sbin/dtrace -s这一行定义了这段脚本是由dtrace来解释，意思和#!/bin/bash差不多，sysinfo::
calls
制定了一个探测点，它告诉系统说在发生xcalls的时候，你给我做下面的事情 @name[execname] = count()，
execname告诉系统说你给我记下是哪个程序造成了xcall，count让系统记录下该程序造成xcall的次数。
从这个列子大家可以看到下面几点：1，dtrace脚本的写法是围绕探测点来组织的，系统里面的探测点可以用dtrace -l 来列出。2，dtrace脚本的语法和C语言比较相似。3，探测点的四元组并不是每个都需要，比如sysinfo::
calls就没有模块和函数这部分。4，dtrace一旦掌握，威力强大，使用简单，你觉得呢?
再来看个列子，比如我们想看各个程序到底打开了那些文件，我们可以建个文件，拷贝下面的内容，然后保存为fileopenedd.d
#!/usr/sbin/dtrace -s
syscall:
pen*:entry
{
printf("%s %s\n",execname,copyinstr(arg0));
}
在终端里面dtrace -s fileopened.d，等一段时间，可以看到类似下面的输出
1 69789 open64:entry firefox-bin .mozilla/firefox/wfkmwmfj.default/sessionstore.js
1 69789 open64:entry firefox-bin .mozilla/firefox/wfkmwmfj.default/sessionstore-1.js
1 69789 open64:entry firefox-bin .mozilla/firefox/wfkmwmfj.default/sessionstore-1.js
大家可以看到firefox这个程序打开了.mozilla/firefox/wfkmwmfj.default/sessionstore.js这些文件。syscall:
pen*:
entry表明了我们探测点是syscall也就是系统调用这个模块来提供的，这里省去了模块，open*是函数的名字，也就是任何的open，
entry表明了这个探测点是这个函数入口的时候， printf("%s
%s\n",execname,copyinstr(arg0)); arg0是open*的入口参数的第一个，也就是打开的文件名。因为
dtrace是在内核里面运行的所以我们要用copyinstr把文件名拷入内核。
大家可以把上面的open*修改成write*就可以看到各个程序修改了哪些文件。
系统里面的探测点平时是关闭的，不会影响我们系统运行的性能。只有我们在dtrace脚本里面激活一个探测点才打开一个探测点，所以装了dtrace的系
统平时的性能是没有影响的，而在使用dtrace的时候，对性能的影响取决于dtrace脚本的写法，但一般来说对性能的影响很小。
这部分先写这么多，写多了估计大家都没兴趣看了。附件是一个很好的资料，虽然是给学生看的，但是确是dtrace入门的极好的教材。
下次将写dtrace的系统介绍，这次是个大概的感性介绍。
[
本帖最后由 niupigege 于 2008-11-20 12:51 编辑 ]
(1.16 MB)
