DTRACE简介之完结篇3

       已经有好长一段时间没有更新blog了，不是我懒，确实是这段时间太忙。工作加上生活，算了，不找借口了，还是来把DTRACE简介作个完结吧。本来开始写的时候只准备用一篇文章来描述，等真正写出来就发现，不行了，Dtrace实在是太强大了，即便是加上今天的，也没有完全讲到，遗漏的地方就只有请各位看官自己去阅读《Solaris 动态跟踪指南》了。

        看完了前面3篇文章的朋友对Dtrace的功能及D语言已经有了一个基本的认识了吧，那你们有没有发现少了点什么？我们提到了Dtrace提供器，但是在前面3篇文章中没有对Dtrace提供器作介绍。Dtrace提供器是Dtrace体系架构的精华，如果不了解Dtrace提供器，那么你就不能充分利用Dtrace。我们也提到，Dtrace提供器随操作系统版本和加载模块的情况有所不同，因此，我们在这里介绍的，也是基本的Dtrace提供器。提供器提供了探测器，探测器提供了参数，不同提供器的探测器参数是不一样的。

dtrace提供器

       注意，不要把“dtrace提供器”和“Dtrace提供器”搞混了，前者只是后者的一个具体提供器（所以我们用小写以区分）。dtrace提供器提供了多个与Dtrace本身相关的探测器。

表1 － dtrace提供器提供的探测器 

ERROR探测器的参数见下表:

表2 － ERROR探测器参数

lockstat 提供器

        lockstat提供器提供了与锁竞争相关的统计信息的探测器。lockstat(1M)命令就是lockstat提供器的使用者。在介绍lockstat提供器之前，先简单介绍一下内核中锁的相关知识。

        现在的操作系统，已经不在是“原始社会”的DOS，只能允许一个任务独占CPU资源，现在的操作系统都是多用户多任务的作业系统，即便是在单CPU的硬件平台上，也可以“同时”并行执行多个任务（注意单CPU系统中的同时指的是在一个时间段，而不是某个时刻）。如果多个任务同时对同一份数据进行修改，势必会造成问题，这时，我们就需要引入“锁”机制用以确保一个时刻只有一个任务对某份数据进行修改。

        所谓“锁”，简单的讲，就是内存中的一段数据，其最简单的形式是一个字节(byte)。内核中的很多数据结构都提供了相关的锁，有的锁是在内核源代码中定义的，有的锁则是在内核运行过程中动态产生的，其中动态产生的锁占内核锁的大部分。一个被占有的锁用锁字节‘0xff‘表示，一个空闲的锁用‘0x00‘表示。现代计算机系统都提供了对锁的原子操作指令，比如SPARC V9中的ldstub(Load and store unsigned byte), cas(compare and swap), swap(swap byte locations)，这些指令可以保证在读取锁字节值的同时对锁字节进行赋值。在对带锁的数据进行访问之前，必须先获得对锁的控制权，否则不能进行访问（当然，这是内核制定的“游戏规则”，在内核中运行必须遵循这些规则，否则就会造成数据的破坏）。在使用完相关的数据之后，应该及时释放锁，否则可能会导致性能问题甚至“死锁”。

        内核中主要有两种锁： 互斥锁(Mutex Lock)和读写锁(Reader/Writer Lock)。当对互斥锁进行访问时，如果访问者发现互斥锁已经被占有(即其值为0xff)，访问者可以进入一个循环等待(Spin)，或者进入睡眠（sleep），缺省情况下互斥锁都是自适应的(Adaptive)，即当锁的持有者在CPU上运行时，访问者进入循环，并在每次循环结束时检查锁是否被释放；当锁的持有者不在CPU上运行时，访问者进入睡眠。只有当执行不允许休眠的代码（比如高级别中断）时，互斥锁才必须是spin类型的（此时也称为自旋锁）。内核中绝大部分互斥锁都是自适应的。读写锁只允许一个对锁的写持有者（修改锁保护的数据），或者多个读持有者（只读取锁保护的数据）。
        lockstat提供器提供了两种类型的探测器：竞争事件(contention-event)探测器和持有事件(hold-event)探测器。

        竞争事件探测器对应于同步原语的竞争，在一个线程被迫等待资源时触发。Solaris已经对竞争进行了优化，因此长时间的竞争是不会发生的。由于竞争的数量很少，因此启用竞争事件探测器不会影响系统性能。

         持有事件探测器对应于对锁的获取、释放及其它操作的同步原语。由于Solaris中对锁的获取和释放操作非常频繁（在一个繁忙的系统上，每秒钟每个CPU数以百万计），启用这些探测器对系统的影响要比启用竞争探测器大，尽管如此，仍是安全的。

          下表是lockstat提供器提供的与自适应锁相关的探测器，其arg0都包含指向代表相关自适应锁的kmutex_t结构指针（可以使用 echo "::print -t kmutex_t"|mdb -k来查看kmutex_t的具体结构）

          表3 － 自适应锁探测器

           表4 － 自旋锁探测器

           线程锁(Thread locks)是一种特殊类型的自旋锁，它用于锁定线程以改变其状态。

          表5－ 线程锁探测器

        读写锁允许对锁的多个读持有者或者一个写持有者，但不允许同时存在读持有者和写持有者。读写锁多用于搜索操作多于更改操作的数据结构中。读写锁探测器的arg0包含指向相关自适应锁的krwlock_t结构的指针。

         表6 － 读写锁探测器

 profile 提供器

         profile提供器提供了与按指定时间间隔触发和基于时间的中断相关的探测器。这些不固定(unanchored)的探测器不与任何特定的执行点关联，而是与异步中断相关联（与之对应的是同步中断，更多时候称为陷阱 trap，即在程序执行过程中的固定点发生的，比如系统调用）。这些探测器可用于对系统某些方面进行采样。

        表7 － profile探测器的参数

       由于进程要么执行在用户态，要么执行在内核态，因此arg0和arg1在同一时刻有且仅有一个为0。

       表8 - profile探测器

        关于时钟精度(Timer Resolution)

        profile提供器使用了操作系统的任意精度时钟。对于没有提供任意精度时钟的硬件平台，触发的频率将受限于系统的时钟频率，有hz内核变量指定，如果profile指定的频率大于系统的时钟频率，则每个时钟间隔将触发多次profile探测器。比如在 hz=100的系统上（即每秒钟中断100次），如果指定profile-1000，则每10微秒将触发10次profile探测器(而非每一微秒触发一次)。

        profile提供器是动态产生探测器的，只有当被启用后才会有相应的探测器产生，因此在没有启用profile探测器之前，dtrace -lP profile是看不到任何东西的。下面的pid提供器也是如此。

FBT提供器

        函数边界跟踪(Function Boundary Tracing -FBT)提供器提供了对Solaris内核绝大多数函数的进入和退出相关的探测器。内核中还有很小一部分函数，这种函数不调用其它的函数，被编译器高度优化成为所谓的“叶函数(Leaf Function)”。“叶函数”不能被FBT利用，在DTRACE中没有与之相关的探测器。

        对FBT提供器的有效使用需要具备相关的操作系统内核知识，对于初学者，建议使用syscall,proc,sched等探测器。

        FBT提供器提供两类探测器，entry在进入相应的函数时被触发，return在从相应的函数返回时被触发。

        表9 - FBT探测器参数

 syscall提供器

        syscall提供器是dtrace最重要的一个提供器，也非常适合初学者使用。syscall提供器在每个系统调用的入口和返回处提供探测器，因此syscall的探测器总是成对的：entry－在进入相应的系统调用之前触发；return－在系统调用完成，但在返回用户态之前触发。syscall探测器的函数名与被检测的系统调用名一致，基本上都可以在/etc/name_to_sysnum文件中找大，详细信息还可以在第2章手册页查到(man -s2 intro)。有些系统调用还有相对应的64位形式（针对大于32位即4G文件的操作），见下表：

       表10－ syscall大文件探测器

         有关大文件的信息，可以参考largefile(5)手册页。

         在不确定的情况下，建议你把大文件syscall探测器也启用。

         对应entry探测器，其参数(arg0...argn)对应于相应的系统调用（注意没有args[]数组）；对于return探测器，arg0和arg1都包含系统调用的返回值。D变量errno如果非0，表示系统调用失败。

         注意：系统调用返回值与errno是不一样的。只有根据相关系统调用手册，在判断返回值是出错的情况时，才能使用errno，否则不能使用，因为errno有可能是上一次系统调用的错误代码。 

SDT提供器

        静态定义跟踪(SDT)提供器在软件研发人员指定的位置创建探测器（有点类似于断点的概率） 。Solaris内核已经定义了一些SDT探测器，以后可能还会增加。软件开发人员也可以按照DTRACE规范定义自己的静态跟踪探测器。

        表11－ SDT探测器

sysinfo提供器

        sysinfo提供器提供了按名称sys分类的与内核统计信息相关的探测器。这些统计信息提供了系统监控程序比如mpstat(1M)的数据。sysinfo探测器在相应的系统计数器增加前瞬间触发。

        表12－ sysinfo探测器

         表13 － sysinfo 探测器参数

vminfo提供器

     vm提供器提供了与虚拟内存管理(Virtual Memory)相关的内核统计数据。

       表14－ vminfo探测器

          表15 － vminfo探测器参数

proc提供器 

       proc提供器提供了与进程创建和终止，LWP创建和终止，执行新的程序已经发送和处理信号相关的探测器。

       表16 － proc探测器

          表17－ proc探测器参数

          下面是上表中Dtrace定义的lwpsinfo_t数据结构

typedef struct lwpsinfo {
    int pr_flag;              /\* 进程状态标志 \*/
    id_t pr_lwpid;            /\* LWP ID号 \*/
    uintptr_t pr_addr;        /\* 线程数据结构在内核中的地址 \*/
    uintptr_t pr_wchan;       /\* 睡眠线程等待的同步对象的地址（比如互斥锁，读写锁等） \*/
    char pr_stype;            /\* 同步事件的类型 \*/
    char pr_state;            /\* 数字表示的线程状态 \*/
    char pr_sname;            /\* 可打印的线程状态 \*/
    char pr_nice;             /\* CPU使用的nice值 \*/
    short pr_syscall;         /\* 系统调用号(/etc/name_to_sysnum），只在线程执行系统调用时有效 \*/
    int pr_pri;                      /\* 优先级，值越大优先级越高 \*/
    char pr_clname[PRCLSZ];   /\* 进程调度分类名 \*/
    processorid_t pr_onpro;   /\* 上一次运行此线程的处理器 \*/
    processorid_t pr_bindpro; /\* 此线程捆绑的处理器 \*/
    psetid_t pr_bindpset;     /\* 此线程捆绑的处理器集 \*/
} lwpsinfo_t;
          

           Dtrace定义的psinfo_t结构

typedef struct psinfo {
    int     pr_nlwp;            /\* 当前进程的活跃的LWP的数量 \*/
    pid_t   pr_pid;             /\* 唯一的进程PID \*/
    pid_t   pr_ppid;            /\* 父进程的PID \*/
    pid_t   pr_pgid;            /\* 进程组领导进程的PID \*/
    pid_t   pr_sid;             /\* 会话ID \*/
    uid_t   pr_uid;             /\* 实际用户ID \*/
    uid_t   pr_euid;            /\* 有效用户ID \*/
    gid_t   pr_gid;             /\* 实际组ID \*/
    gid_t   pr_egid;            /\* 有效组ID \*/
    uintptr_t pr_addr;          /\* 进程数据结构在内核中的地址 \*/
    dev_t   pr_ttydev;          /\* 此进程控制的TTY设备 (如果未与TTY关联，则为 PRNODEV) \*/
    timestruc_t pr_start;       /\* 从UNIX纪元开始的进程启动时间 \*/
    char    pr_fname[PRFNSZ];   /\* 执行文件的名字 \*/
    char    pr_psargs[PRARGSZ];  /\* 参数列表 \*/
    int     pr_argc;                         /\* 参数个数 \*/
    uintptr_t pr_argv;            /\* 参数向量的地址 \*/
    uintptr_t pr_envp;          /\* 环境变量的地址 \*/
    char    pr_dmodel;          /\* 程序的数据模式（ILP32或者LP64) \*/
    taskid_t pr_taskid;         /\* 任务ID \*/
    projid_t pr_projid;         /\* 项目ID \*/
    poolid_t pr_poolid;         /\* 资源池ID \*/
    zoneid_t pr_zoneid;         /\* 分区ZONE ID \*/
} psinfo_t;

sched提供器

      sched提供器提供与CPU调度相关的探测器。

       表18－sched探测器

         表19－sched探测器参数

          下面是sched提供中中需要用到的cpuinfo_t结构

typedef struct cpuinfo {
    processorid_t cpu_id;      /\* CPU 标志 \*/
    psetid_t cpu_pset;         /\* 处理器集标志 \*/
    chipid_t cpu_chip;         /\* 芯片标志 \*/
    lgrp_id_t cpu_lgrp;        /\* 位置组标志 \*/
    processor_info_t cpu_info; /\* CPU 信息 \*/
} cpuinfo_t;

io提供器

    io提供器提供了与磁盘及NFS输入输出操作相关的探测器。

    表20－io探测器

          下面是参数中会用到的结构

typedef struct bufinfo {
    int b_flags;         /\* 标志 \*/
    size_t b_bcount;     /\* 字节数\*/
    caddr_t b_addr;      /\* 缓冲区地址 \*/
    uint64_t b_blkno;    /\* 设备上的扩展块号 \*/
    uint64_t b_lblkno;   /\* 设备块号 \*/
    size_t b_resid;      /\* 未传输的字节数 \*/
    size_t b_bufsize;    /\* 分配的缓冲区的大小 \*/
    caddr_t b_iodone;    /\* I/O完成执行的程序 \*/
    dev_t b_edev;        /\* 设备号 \*/
 } bufinfo_t;

typedef struct devinfo {
    int dev_major;       /\* 主设备号 \*/
    int dev_minor;       /\* 次设备号 \*/
    int dev_instance;    /\* 实例号 \*/
    string dev_name;     /\* 设备名 \*/
    string dev_statname; /\* 设备名+实例号/次设备号 \*/
    string dev_pathname; /\* 设备路径名 \*/
} devinfo_t;

typedef struct fileinfo {
    string fi_name;       /\* 文件名(不带目录部分) \*/
    string fi_dirname;    /\* 目录名 \*/
    string fi_pathname;   /\* 绝对路径名 \*/
    offset_t fi_offset;   /\* 文件内的偏移地址 \*/
    string fi_fs;         /\* 文件系统 \*/
    string fi_mount;      /\* 文件系统安装点 \*/
} fileinfo_t;
    

        除此之外，还有pid提供器、mib提供器、fpuinfo提供器、plockstat提供器、fasttrap提供器等，限于时间关系，我就不在这里介绍了。感兴趣的朋友建议仔细阅读《Solaris动态跟踪指南》。