OpenSolaris新特性解析之五: dtrace1-基础

niupigege

http://bbs.chinaunix.net/viewthr ... page%3D1#pid9661083

该系列前面的帖子:

OpenSolaris新特性解析之一:Opensolaris之前身今世    http://bbs.chinaunix.net/viewthread.php?tid=1221539
OpenSolaris新特性解析之二:ZFS                              http://bbs.chinaunix.net/viewthread.php?tid=1234907
OpenSolaris新特性解析之三:SMF                             http://bbs.chinaunix.net/viewthread.php?tid=1273723
OpenSolaris新特性解析之四:FMA                             http://bbs.chinaunix.net/viewthread.php?tid=1295237

这个系列的第五篇文章准备介绍下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的系统介绍，这次是个大概的感性介绍。