【申请加精】来自UC的《Solaris 10红宝书》系列在线课程

luren04

17.1 信息管理概述   
Solaris系统信息共有三个类型：日志信息、Core信息和Crash信息。显示系统信息的地方通常是控制台和日志文件。当然，Solaris系统也提供控制台信息转储的方法。

对于显示在系统控制台中的，系统信息的内容一般如此：

[ID msgid facility.priority]

举例说明：

[ID 672855 kern.notice] syncing file systems...

如果信息来自于内核，内核的名字会显示出来，比如：

Oct 1 14:07:24 mars ufs: [ID 845546 kern.notice] alloc: /: file system full

当系统崩溃时，可能在控制台显示的信息是这样：

panic: error message

在不经常的情况下，下面的信息可能会替代panic信息：

Watchdog reset !

在日志中，记录日志程序syslogd可以自动记录各种系统的警告和错误信息。在默认情况下，很多系统信息显示在系统控制台并存储在/var/adm目录中。当系统发生问题，比如有些设备发生了故障时这些信息能给出警告。

/etc/adm目录包含着几个信息文件。最新的信息是存储在/var/adm/messages文件中。经过一段时间之后（通常是每10天），新的消息文件就会被创建，这时messages.0文件就改名为messages.1，messages.1该为messages.2，messages.2改为messages.3等。而原来的messages.3文件将被删除。

因为/var/adm目录存有大容量的信息文件、crash文件和其他数据文件，所以这个目录需要大的磁盘空间。你应该删除在这个目录中的一些不需要的文件。

要想查看当前系统内核崩溃信息或重新启动信息，请使用dmesg命令。当然也可以直接到/var/adm/messages文件中去查看。

dmesg命令输入如下所示：

$ dmesg

Jan 3 08:44:41 starbug genunix: [ID 540533 kern.notice] SunOS Release 5.10 ...

Jan 3 08:44:41 starbug genunix: [ID 913631 kern.notice] Copyright 1983-2003 ...

Jan 3 08:44:41 starbug genunix: [ID 678236 kern.info] Ethernet address ...

Jan 3 08:44:41 starbug unix: [ID 389951 kern.info] mem = 131072K (0x8000000)

Jan 3 08:44:41 starbug unix: [ID 930857 kern.info] avail mem = 121888768

Jan 3 08:44:41 starbug rootnex: [ID 466748 kern.info] root nexus = Sun Ultra 5/

10 UPA/PCI (UltraSPARC-IIi 333MHz)

Jan 3 08:44:41 starbug rootnex: [ID 349649 kern.info] pcipsy0 at root: UPA 0x1f0x0

Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] pcipsy0 is /pci@1f,0

Jan 3 08:44:41 starbug pcipsy: [ID 370704 kern.info] PCI-device: pci@1,1, simba0

Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] simba0 is /pci@1f,0/pci@1,1

Jan 3 08:44:41 starbug pcipsy: [ID 370704 kern.info] PCI-device: pci@1, simba1

Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] simba1 is /pci@1f,0/pci@1

Jan 3 08:44:57 starbug simba: [ID 370704 kern.info] PCI-device: ide@3, uata0

Jan 3 08:44:57 starbug genunix: [ID 936769 kern.info] uata0 is /pci@1f,0/pci@1,

1/ide@3

Jan 3 08:44:57 starbug uata: [ID 114370 kern.info] dad0 at pci1095,6460



luren04

17.2 系统日志信息管理   
日志（log）是最常见的日志形式。本节主要介绍日志的利用和管理。

17.2.1 系统日志循环利用
系统日志文件是通过在/etc/crontab文件中设定，定时启动logadm命令来完成循环利用的。创建新的日志记录的脚本程序/usr/lib/newsyslog并不经常起用。

系统日志循环是定义在/etc/logadm.conf文件中的，这个文件包含着日志进程的循环条目。比如，其中一个条目就是关于/var/log/syslog文件每周循环的，最新的syslog文件成为syslog.0文件，而syslog.0成为syslog.1文件等。一共保存8个以前的日志文件。

在/etc/logadm.conf中，你可以定制系统日志或增加系统日志的记录。

比如，循环增加apache的访问和错误日志，就用下列命令：

# logadm -w /var/apache/logs/access_log -s 100m

# logadm -w /var/apache/logs/error_log -s 10m

在这个例子中，apache的access_log文件当达到100MB时是循环使用的，使用的文件后缀是0，1，2等，一共保存10个access_log文件的拷贝。error_log也是循环的，当它达到10MB的时候停止保存。

17.2.2 定制系统日志信息
定制系统日志信息输出的文件是/etc/syslog.conf文件。在/etc/syslog.conf文件中，默认设置下，很多系统进程信息被保存到/var/adm/messages 文件。crash和启动信息也可以这里设置。

下面就是/etc/syslog.conf文件的内容：

user.err /dev/sysmsg

user.err /var/adm/messages

user.alert ‘root, operator’

user.emerg *

这意味着下列信息可以自动记录：

 用户的错误打印在控制台上并且记录在/etc/adm/messages文件中

 要有一个动作（alert）来响应信息，这个动作给root或操作的用户发送警告。

 用户的紧急情况信息要发送给每个人。

在syslog.conf文件中的资源工具在表17-1中列出。在此文件中的优先级列表为表17-2。

表17-1 在syslog.conf文件中的资源工具

资 源
描 述

kern
内核

auth
权限

daemon
所有后台程序

mail
邮件系统

lp
打印系统

user
用户进程


表17-2 在syslog.conf文件中的优先级列表

优 先 级
描 述

emerg
系统突发紧急事件

alert
错误要求马上修正

crit
危急的错误

err
其他错误

info
情报信息

debug
输出用户调试信息

none
设定不进行日志输出


下面举例说明如何定制日志信息：

 例17-1 定制日志信息。

（1）成为超级用户或等同角色用户。

（2）编辑/etc/syslog.conf文件，增加下面的内容，将用户的突发事件信息发送给超级用户和每个用户。

user.emerg ‘root, *’

（3）退出保存。

luren04

17.3 系统core文件的管理   
core文件是系统软件出现问题后产生的信息记录。它对软件开发者和系统管理者的工作有很大的帮助作用。本节主要对Core文件产生和管理做一些初步介绍。

17.3.1 管理core文件概述
core文件在进程或者应用程序异常终止时产生。我们可以使用coreadm命令来管理core文件。比如，你可以使用coreadm命令来设定所有的core文件都放在一个目录中。这样，就会很容易通过测试找到问题的痕迹。

有两种类型的core文件：

 单个进程的core文件，在默认情况下是启动的。当进程异常终止时，单个进程的core文件就在异常终止进程的目录中产生。产生后，单个进程的core文件的拥有者就是进程的拥有者。只有拥有者才能查看这个文件。

 全局core文件，它默认的情况下是不开启的。如果启动了全局core文件，它产生在引起全局core文件产生的目录。全局core文件的拥有者就是超级用户。非特权用户不能查看全局core文件。

当进程异常终止时，默认在当前目录产生core文件。如果这时全局core文件路径也开启着，每个异常终止的进程就会有两个文件产生：一个在当前的工作目录；另一个在全局core文件目录。

默认时，setuid进程既不产生全局core文件也不产生单个core文件。

如果全局core文件是开启的，core文件可以用表17-3中的变量所描述。

表17-3 描述Core文件的变量

变 量 名
变量描述

%d
执行的文件目录名

%f
执行的文件名

%g
组的ID

%m
机器名称


续表

变 量 名
变量描述

%n
系统节点名

%p
进程ID

%t
十进制的时间

%u
有效的用户ID

%z
进程运行的分区（xone）名

%%
百分比


举例说明，全局core文件路径设置为：

/var/core/core.%f.%p

这时，如果sendmail的PID为12345的进程发生异常终止，将产生下列core文件：

/var/core/core.sendmail.12345

我们可以使用coreadm命令设定进程产生的core文件的目录和名称。这将取代原来的默认设置。

# coreadm -i /var/core/core.%f.%p

全局core的属性值存储在/etc/coreadm.conf文件中。

17.3.2 管理core文件的实例
1．显示当前core文件的设置
 例17-2 使用不带任何参数的coreadm命令显示当前core的设置情况。

$ coreadm

global core file pattern:

global core file content: default

nit core file pattern: core

init core file content: default

global core dumps: disabled

per-process core dumps: enabled

global setid core dumps: disabled

per-process setid core dumps: disabled

global core dump logging: disabled

2．设置core文件名的样式
将当前Shell运行的所有进程所产生的core文件命名：

$ coreadm -p $HOME/corefiles/%f.%p $$

对全局文件设置core文件命名需要超级用户权限：

# coreadm -g /var/corefiles/%f.%p

3．启用单个进程core文件的路径
# coreadm -e process

$ coreadm $$

1180: /home/kryten/corefiles/%f.%p

4．启用全局core文件的路径
# coreadm -e global -g /var/core/core.%f.%p

17.3.3 查询core文件信息
一些proc工具可以像检测活动的进程一样检测core文件。比如，/usr/proc/bin/pstack、pmap、pldd、pflags和pcred工具能管理core文件。更详细的信息请查看porc(1)的帮助。

 例17-3 使用proc工具检查core文件。

$ ./a.out

Segmentation Fault(coredump)

$ /usr/proc/bin/pstack ./core

core ’./core’ of 19305: ./a.out

000108c4 main (1, ffbef5cc, ffbef5d4, 20800, 0, 0) + 1c

00010880 _start (0, 0, 0, 0, 0, 0) + b8

luren04

17.4 系统crash信息的管理   
crash主要反馈主机能否正常运行等比较严重的问题。系统管理员需要特别关注crash信息。

17.4.1 系统崩溃概述
系统崩溃（crash）发生在硬件故障、I/O问题或软件错误的情况下。如果系统崩溃发生了，它将在控制台上显示错误信息，并将物理内存的拷贝写入转储设备。这时，系统将自动重新启动。当系统重启后，savecore 命令运行将数据从转储设备中找回，并存储到savecore目录。这些数据为系统诊断提供了依据。

系统崩溃转储文件
当savecore命令自动运行将崩溃信息从转储设备中找回，并写成两个文件：unix.X和vmcore.X。其中X为转储的次序号码。这些文件一起用于表现系统的崩溃转储信息。

崩溃转储文件存储在预先设定好的目录中，默认情况下是/var/crash/hostname。在以前的Solaris版本中，崩溃转储文件将在系统重新启动的时候不写在特定的目录，除非你手动启动，将内存的映像存储到崩溃转储文件中。不过现在就自动存储崩溃转储文件了。

dumpadm命令
我们可以用dumpadm命令来在Solaris系统中管理系统崩溃转储信息。

 dumpadm命令能使你在操作系统上设置崩溃转储。这个命令的设置参数包括转储的内容、转储的设备和崩溃转储信息的存储路径。

 转储数据是以压缩的形式被存在转储设备中的。内核的崩溃转储映像可能达到4GB，压缩数据就意味着更快的转储速度和更小的转储设备磁盘空间。

 保存崩溃转储文件是在后台运行的崩溃转储文件的任务。系统启动的时候不需要等待savecore命令完成就可以进行下一步。当然，大的内存数量是有利于savecore完成任务的。

 系统崩溃转储文件是由savecore命令产生的，保存一般也是按默认路径进行的。

 savecore –L命令是新的属性，它使你能在系统运行的时候崩溃转储。当系统内存存储有问题的时候，这个命令试图在系统运行的时候调试内存的快照。如果系统是启动的，并且有些命令还能执行，你可以运行cavecore –L命令来存储系统转储设备的快照到崩溃转储目录。

通过dumpadm命令，转储设置参数存储在/etc/dumpadm.conf文件中。注意不要手动编辑这个文件，这样做可能会带来不一致的转储设置。

dumpadm命令如何工作
当系统启动的时候，dumpadm命令调用svc:/system/dumpadm:default服务来设置基于/etc/dumpadm.conf文件的的崩溃转储参数。

dumpadm命令通过/dev/dump接口来初始化转储设备和转储内容。

17.4.2 管理系统崩溃转储信息
在管理系统崩溃信息中，你必须要记住以下几点：

 你必须是超级用户或具有管理系统崩溃功能的用户。

 不要关闭保存崩溃转储信息的属性。系统崩溃转储文件提供了导致系统崩溃的很珍贵的信息。

 不要轻易删除系统崩溃信息。

1．如何显示当前的崩溃转储设置
# dumpadm

Dump content: kernel pages

Dump device: /dev/dsk/c0t3d0s1 (swap)

Savecore directory: /var/crash/venus

Savecore enabled: yes

上面输出的意义如下：

 转储内容是内核内存的换页。

 内核内存将转储到swap设备中，就是/dev/dsk/c0t3d0s1。

 系统崩溃转储文件存在/var/crash/venus目录。

 系统的崩溃转储功能是启动着的。

2．如何修改当前的崩溃转储设置
命令介绍

# dumpadm -c content -d dump-device -m nnnk | nnnm | nnn% -n -s savecore-dir

dumpadm命令的各个参数具体意义列在表17-4中。

表17-4 dumpadm命令的参数列表

转储参数
描 述

-c content
转储的数据类型。默认的转储内容是内核的内存。使用all关键字是指所有内存

-d dump-device
系统崩溃时，临时存储的专门设备

-m nnnk | nnnm | nnn%
在savecore目录中为了存储崩溃转储文件所留的专门空间。这个参数有可能是kb（nnnk），也有可能mb（nnnm），也有可能是百分比(nnn%)

-n 或-y
是否自动进行崩溃转储，y为是，n为否

-s savecore-dir
用来改变崩溃转储文件的路径。默认路径是/var/crash/hostname


 例17-4 转储内容改为所有内存，转储目录改为/dev/dsk/c0t1d0s1，转储空间最大为这个文件系统的10%。

先查看原来的转储设置：

# dumpadm

Dump content: kernel pages

Dump device: /dev/dsk/c0t3d0s1 (swap)

Savecore directory: /var/crash/pluto

Savecore enabled: yes

更改转储设置：

# dumpadm -c all -d /dev/dsk/c0t1d0s1 -m 10%

Dump content: all pages

Dump device: /dev/dsk/c0t1d0s1 (dedicated)

Savecore directory: /var/crash/pluto (minfree = 77071KB)

Savecore enabled: yes

3．如何检查崩溃转储文件内容
 例17-5 使用mdb工具输出崩溃转储文件内容，其中包括系统信息和在/etc/system文件中可调用的一些参数。

# /usr/bin/mdb -k unix.0

Loading modules: [ unix krtld genunix ip nfs ipc ptm ]

> ::status

debugging crash dump /dev/mem (64-bit) from ozlo

operating system: 5.10 Generic (sun4u)

> ::system

set ufs_ninode=0x9c40 [0t40000]

set ncsize=0x4e20 [0t20000]

set pt_cnt=0x400 [0t1024]

luren04

第18章 Solaris 10动态跟踪技术   
如果你想了解系统的行为，DTrace是很好的工具。DTrace是管理员和开发者用来全面测试应用软件和系统的行为的动态跟踪工具。DTrace使你浏览你的系统，并理解它是如何工作的。正像你看到的那样，DTrace可以使你使用D语言创造自己的工具来要求系统回答你的问题。

DTrace，即动态跟踪Dynamic Tracing，是Solaris 10或Solaris 10的一个新功能。通过此功能，用户能够动态检测操作系统内核和用户进程，以更精确地掌握系统的资源使用状况，提高系统性能，减少支持成本，并进行有效的调节，发现先前隐蔽的系统问题，并且修复过去无法解决的性能问题。借助DTrace，你可以：

 检查用户程序及Solaris操作系统的行为，快速找出造成系统和应用程序瓶颈的根本起因。

 突出系统调节的趋势和模式，以获得最佳性能。

 捕捉到软件不同层级之间的性能问题。

 找出异常行为的起因。

 为普通或复杂的例行程序编写可重复使用的脚本。

 指定DTrace收集的数据、采取的操作，以及在哪些条件下采取这些操作。

luren04

18.1 动态跟踪（DTrace）原理   
本节主要介绍动态跟踪技术（DTrace）的原理。

18.1.1 动态跟踪（DTrace）的概念
在理解软件系统时记录下来的特定的数据点的位置，叫做指针，也叫探测器（probe）。在探测器上，DTrace可能需要执行一些任务，被称为actions，比如记录一些痕迹、期次、功能等。探测器像可以编程的传感器，分散到系统中的所有部位。如果你对那些部位感兴趣，可以编程去采集这些部位的传感器的数据。要是你没有专门的任务给这些探测器，那么它们将只负责记录信息。

Solaris中有30 000多个位置分散着指针探测器，DTrace可激活成千上万的探测器，记录所关注的位置指定的数据，如命中，即可从该地址显示用户进程或系统内核的数据，从而了解系统，具体信息包括：

 任何函数的参数；

 内核的任何全局变量；

 函数调用的时间（NS，十亿分之一秒，无任何其他PC/UNIX在ns一级精度）；

 跟踪堆栈，包括指明函数调用的代码；

 函数调用时运行的进程；

 产生函数调用的线程。

每个探测器都有两个名字：惟一的数字ID和人们比较容易理解的字符名。先学一个简单的探测器，“BEGIN”，它是我们每次开始新的跟踪之前必须使用的。使用DTrace(1M)命令和-s选项可以应用这个探测器：

# DTrace -n BEGIN

运行之后稍微等待一会，你将看到下面的输出，按CtrlC键能返回你原来的shell：

# DTrace -n BEGIN

DTrace: description ’BEGIN’ matched 1 probe

CPU ID FUNCTION:NAME

0 1 :BEGIN

^C

#

输出的内容说明了探测器的名字叫“BEGIN”，数字ID是“1”。CPU栏目中显示“0”是指CPU的ID，说明CPU 0运行了这个探测器。

你可以使用DTrace命令来构建任何ID号码的探测器和动作（actions）。比如使用两个探测器“BEGIN”和“END”。“END”探测器是最后完毕时执行的：

# DTrace -n BEGIN -n END

DTrace: description ’BEGIN’ matched 1 probe

DTrace: description ’END’ matched 1 probe

CPU ID FUNCTION:NAME

0 1 :BEGIN

^C

0 2 :END

#

可以看到，当使用CtrlC退出DTrace时，触发了END探测器。

在理解了上述内容之后，就可以试着写第一个D程序了：“Hello，World”。创建一个文件hello.d。

 例18-1 创建文件hello.d。

BEGIN

{

trace("hello, world");

exit(0);

}

保存好这个文件，然后使用-s选项运行这个文件：

# DTrace -s hello.d

DTrace: script ’hello.d’ matched 1 probe

CPU ID FUNCTION:NAME

0 1 :BEGIN hello, world

#

每个D程序由一系列的语句组成，每个语句描述一个或多个探测器或探测器的动作。这些动作列在大括号{}内。每个声明的结尾由分号（；）结束。本例中trace("hello, world")是指当运行BEGIN探测器后，将变量“hello，world”打印出来。exit()是指DTrace将要退出跟踪结束DTrace命令。

从这里可以看出，D语言和C语言非常相似。它是C语言的子集，如果你以前写过C 语言，你就能很快学会写D语言。

18.1.2 提供者（Providers）和探测器
在前面的例子中，我们学会了两个简单的探测器BEGIN和END。那么这些探测器是从哪里来的呢？这些探测器来自于叫做providers的内核模块集，它也是探测器的分类。当你使用DTrace时，提供者给你一个发布他能提供给DTrace框架的探测器的机会，也可以对这个探测器绑定任何可以的动作。在系统中列出所有可用探测器：

# DTrace -l

ID PROVIDER MODULE FUNCTION NAME

1 DTrace BEGIN

2 DTrace END

3 DTrace ERROR

4 lockstat genunix mutex_enter adaptive-acquire

5 lockstat genunix mutex_enter adaptive-block

6 lockstat genunix mutex_enter adaptive-spin

7 lockstat genunix mutex_exit adaptive-release

…

#

这次输出要经过一段时间才能完成。如果要计算探测器的总数，则可以使用下列命令：

# DTrace -l | wc -l

30122

在不同的系统之中，探测器的总数因系统平台和安装软件的变化而变化。但是，正如你所见的那样，在你的系统中有大量的探测器。

我们再来观察DTrace –l的输出，注意到每个探测器都输出了两个名字，即数字ID和有实际意义的名字。这个易读的名字由四部分组成，具体意义如表18-1所示。

表18-1 探测器名字的意义

Provider
发布这个探测器的提供者的名字。这个名字代表了执行探测器的内核模块的名字

Module
如果这个探测器反映了专门程序的区域，此栏目就是探测器位于模块的名字。这个名字既可以是内核模块的名字，也可以是用户库（library）的名字

Function
如果这个探测器反映了专门程序的区域，则此栏目就是这个程序的功能名

Name
探测器的名字


探测器的完整名字：

provider:module:function:name

需要注意的是，有些探测器没有module和function，如BEGIN和END探测器。有些探测器有两个空白的栏目，因为这些探测器不能反映专门程序的功能和区域。比如前面我们介绍过的BEGIN探测器的名字就是DTrace:::BEGIN，它指这个探测器的提供者就是DTrace自己，并且没有module和function。探测器名字中的Provider类型如表18-2所示。

表18-2 Provider的类型

提供者名字
描 述

DTrace
提供者提供了几个关联到DTrace自己的探测器，有BEGING、END和ERRORD等

lockstat
提供者提供有关lock的信息和行为的探测器

profile
提供以专门的时间间隔为基础的探测器

FBT
提供内核功能分界方面的探测器

syscall
提供系统调用的入口和出口的探测器

sdt
提供对软件程序的指定位置的探测器

sysinfo
提供对内核的统计分类信息的探测器

vminfo
提供vm内核的统计信息的探测器

proc
提供有关进程、LWP的创建和终止，运行新的程序映像，以及发送和接受信号的探测器

sched
提供关于CPU调度方面的探测器

io
提供关于磁盘的输入和输出的探测器

mib
提供关于Solaris管理数据库的探测器

fpuinfo
提供在SPARC计算机上浮点运算方面的探测器

pid
提供用户进程的入口和返回方面的探测器

plockstat
提供观察用户级的行为的探测器


通过表18-2可以看出，使用DTrace可以很全面地观察系统。另外，将三万多探测器分类后，也可以方便我们来使用它们。

18.1.3 D语言的简单介绍
举个例子来介绍D语言。我们使用profile提供者来执行一个以时间为基础的记数。这个新的探测器的名字就叫profile:::tick-nsec，n只正整数，就是profile提供者每隔n秒钟来创建一个DTrace执行。我们将这个程序保存在名为counter.d的文件中：

 例18-2

/*

* Count off and report the number of seconds elapsed

*/

DTrace:::BEGIN

{

i = 0;

}

profile:::tick-1sec

{

i = i + 1;

trace(i);

}

DTrace:::END

{

trace(i);

}

运行这个程序：

# DTrace -s counter.d

DTrace: script ’counter.d’ matched 3 probes

CPU ID FUNCTION:NAME

0 25499 :tick-1sec 1

0 25499 :tick-1sec 2

0 25499 :tick-1sec 3

0 25499 :tick-1sec 4

0 25499 :tick-1sec 5

0 25499 :tick-1sec 6

^C

0 2 :END 6

#

熟悉C语言编程的读者可能很容易理解这个脚本程序。D语言和C语言非常类似。不熟悉C语言的读者也不用担心，因为随着D语言的流行，可以在因特网上找到很多现成的D语言工具，可以免费使用。

luren04

18.1.4 DTrace命令介绍
DTrace(1M)命令执行简单的端口调用D语言的编译器，能从DTrace内核工具中找回缓存中数据的踪迹并打印出来。

DTrace命令参数：

# DTrace

Usage: DTrace [-32|-64] [-aACeEFGHlqSvVwZ] [-b bufsz] [-c cmd] [-D name[=def]]

[-I path] [-o output] [-p pid] [-s script] [-U name]

[-x opt[=val]] [-X a|c|s|t]




[-P provider [[ predicate ] action ]]

[-m [ provider: ] module [[ predicate ] action ]]

[-f [[ provider: ] module: ] func [[ predicate ] action ]]

[-n [[[ provider: ] module: ] func: ] name [[ predicate ] action ]]

[-i probe-id [[ predicate ] action ]] [ args ... ]




predicate -> '/' D-expression '/'

action -> '{' D-statements '}'

-32产生32位D程序和ELF32文件。

-64产生64位D程序和ELF64文件。

-a宣布进入匿名跟踪状态。

-A对匿名跟踪产生dirver.conf(4)的指示。

-b设置跟踪的缓存的人小。

-c当命令执行完后，运行专门的命令退出。

-C在脚本文件中运行cpp(1)预处理程序。

-D当调用预处理程序时，定义一个符号。

-e在启动探针之前，完成一定要求后退出。

-E在跟踪数据之前，启动探针后退出。

-f列出匹配特定函数名的探针的名称。

-F按属性进行联合输出。

-G产生包含D语言的EFL文什。

-H当调用预处理程序时，将所包含的文件打印出来。

-i将匹配的专门ID的探针打印出来。

-I增加包含预处理程序的目录。

-1列出匹配专门标准的探针。

-m列出匹配专门模块的探针名。

-n列出匹配专门的名称的探针。

-o设置输出文件。

-p捕捉专门的进程ID和符号表的缓存。

-P列出所匹配提供者名的探针。

-q设置一个平静的模式，只明确输出跟踪的数据。

-s依据专门的D语言脚本列出探针。

-S打印出D语言的编译代码。

-U当调用预处理程序时不定义符号。

-v置详细的模式来报告程序的稳定的属性。

-V报告DTrace的API版本。

-w允许的破坏行为的选项。

-x使用或修改编译器和跟踪属性。

-X使用ISO C来设定预处理程序。

-Z允许匹配“0”探针的描述。

 例18-3 比较DTrace与Solaris系统的ps命令的区别。

如用ps命令查看mozilla进程：

# ps -e |grep mozilla

2386 pts/11 0:00 mozilla

2436 pts/11 10:12 mozilla-

用DTrace的探测器查看此进程，则是：

# DTrace -n 'syscall::exece:return { trace(execname);}'

DTrace: description 'syscall::exece:return ' matched 1 probe

CPU ID FUNCTION:NAME

0 11082 exece:return uname

0 11082 exece:return uname

0 11082 exece:return basename

……

0 11082 exece:return sed

0 11082 exece:return mozilla-bin

1 11082 exece:return csh

1 11082 exece:return mozilla

……

 例18-4 体验date命令和DTrace命令的区别。

如用date命令显示系统时间，很快就结束了，无法跟踪：

% date

2005年05月24日 星期二 20时39分03秒 CST

体验DTrace跟踪效果：

# DTrace -n 'syscall::exece: {trace(timestamp)}'

dDTrace: description 'syscall::exece: ' matched 2 probes

CPU ID FUNCTION:NAME

0 11081 exece:entry 102890531281542

0 11082 exece:return 102890532181875

可以看到，跟踪其在第102890531281542纳秒开始读取，第102890532181875纳秒返回结果。

 例18-5 体验vmstat命令和DTrace命令输出的区别。

如看机器忙闲状态，常用vmstat命令：

bash-3.00# vmstat 1

kthr memory page disk faults cpu

r b w swap free re mf pi po fr de sr cd f0 s0 -- in sy cs us sy id

0 0 0 599168 9736 3 15 5 1 1 0 3 1 0 0 0 276 185 100 1 17 82

0 0 0 611088 21720 0 23 36 0 0 0 0 4 0 0 0 279 146 114 7 38 55

0 0 0 611088 21720 0 0 0 0 0 0 0 4 0 0 0 335 179 134 2 3 95

0 0 0 611088 21720 0 0 0 0 0 0 0 4 0 0 0 330 158 115 2 4 94

0 0 0 611088 21720 0 0 0 0 0 0 0 4 0 0 0 391 303 145 6 4 90

0 0 0 611088 21720 0 0 0 0 0 0 0 4 0 0 0 346 216 117 3 3 94

^C

我们可以看出，系统调用（sy）产生216多个问题，但vmstat没有显示是哪些进程所产生的问题，现在试用DTrace来查看：

# DTrace -n 'syscall::read:entry {@NUM[execname] = count();}'

dDTrace: description 'syscall::read:entry ' matched 1 probe

^C

运行一会，按下^C。出现下面的结果：

automountd 1

nscd 5

ttymon 6

sac 6

dtterm 12

init 12

utmpd 18

dtwm 262

sdtperfmeter 1823

Xorg _ 11166

显然发现Xorg和sdtperfmeter是产生大量系统调用的程序。

详细查看一下：

# DTrace -n 'syscall::write:entry {@NUM[execname] = quantize(arg2);}'

sdtperfmeter

value ------------- Distribution ------------- count

2 | 0

4 | @@@@@@@@@@@@@@@ 3970

8 | 0

可观察到sdtperfmeter产生的I/O都是4个字节。

显然，使用DTrace组合命令要比vmstat命令输出的信息详细得多。

luren04

18.2 使用DTrace工具   
无论对于系统管理员还是程序开发人员来说，DTrace都能带来莫大的方便，它使我们直接观察系统的运行情况。本节将要举一些使用DTrace的实例，使读者直观地感受DTrace的魅力。

18.2.1 Solaris 10系统自带的常用DTrace举例
首先需要说明的是，DTrace只有在Solaris 10系统或更高版本的Solaris中才能应用。并且在这些系统中，也自带一些D语言的脚本程序，它们位于/usr/demo/DTrace目录中。初学者可以先看看这些例子，运行一下，对理解DTrace的使用和D语言的编写会有好处。

进入/usr/demo/DTrace目录后，发现此目录中有下列程序，我们可以直接使用它们，也可以稍加修改再使用。

# cd /usr/demo/dtrace

# ls

applicat.d intr.d qtime.d whatfor.d

badopen.d iocpu.d renormalize.d whatlock.d

begin.d iosnoop.d restest.d where.d

callout.d iothrough.d ring.d whererun.d

clause.d iotime.d rtime.d whoexec.d

clear.d iprb.d rwinfo.d whofor.d

countdown.d kstat.d rwtime.d whoio.d

counter.d ksyms.d sig.d whopreempt.d

dateprof.d libc.d soffice.d whoqueue.d

delay.d lquantize.d spec.d whosteal.d

denorm.d lwptime.d specopen.d whowrite.d

end.d normalize.d ssd.d writes.d

error.d nscd.d sunlogo.gif writesbycmd.d

errorpath.d pri.d syscall.d writeabycmdfd.d

find.d printa.d tick.d writetime.d

firebird.d pritime.d ticktime.d writetimeq.d

hello.d prof.d time.d xioctl.d

howlong.d profpri.d tracewrite.d xterm.d

index.html progtime.d trunc.d xwork.d

interp.d putnext.d trussrw.d

interval.d qlen.d userfunc.d

#

对于这些D语言程序，在使用时候应该选择-s的选项。

 例18-6 检测系统命令的读写时间。

对于某个终端在运行系统命令时，可以用rwtime.d程序来监测读写时间。

首先要弄清楚用户的终端Shell进程号码。方法是打开一个新的终端控制台，在提示符下运行：

#echo $$

623

然后，我们来了解rwtime.d程序：

syscall::read:entry,

syscall::write:entry

/pid == $1/

{

ts[probefunc] = timestamp;

}

syscall::read:return,

syscall::write:return

/pid == $1 && ts[probefunc] != 0/

{

printf("%d nsecs", timestamp - ts[probefunc]);

}

可见启动了syscall探测器，并且需要输入$1变量值。

运行DTrace命令后，可以看到这个程序匹配四个探测器。在id为623的终端控制台上输入任何命令，rwtime.d就会反馈出这个命令运行了多少纳秒。

# dtrace –s rwtime.d 623

dtrace: script ’rwtime.d’ matched 4 probes

CPU ID FUNCTION:NAME

0 14 write:return 4089025 nsecs

0 12 read:return 23530445493 nsecs

0 14 write:return 155161 nsecs

0 14 write:return 78225 nsecs

0 12 read:return 523171473332 nsecs

 例18-7 获得读写操作的统计。

# DTrace -q -s rwinfo.d ‘pgrep -n ksh‘

^C

pgrep -n ksh将输出ksh进程的ID，将此ID输入程序中，程序将反馈出此ksh中的读写统计。

过几分钟后，键入^C。得出下面的结果：

calls max bytes elapsed nsecs

------ ----- --------- -------------

read 36 1024 3588283144

write 35 59 14945541

#

以纳秒的形式显示了读和写操作的时间统计。

18.2.2 使用第三方编写的DTrace工具
如果你没有时间来写D程序或者没有时间来学习写这些程序，也不用担心，在下面链接的网站可以下载一个打包的DTrace工具包：

 http://users.tpg.com.au/adsln4yb/DTrace.html#DTraceToolkit

 http://www.openSolaris.org/os/community/DTrace/DTracetoolkit

 http://www.brendangregg.com/DTrace.html#DTraceToolkit

目前的最新版本是DTraceToolkit-0.84.tar.gz。这个工具包大约有80个脚本程序。

下载后，首先需要使用gunzip和“tar xvf”命令解压缩包。然后，运行./install程序，将这些文件解压缩后放到可以执行的目录。

下面我们详细介绍DTraceToolkit工具包中的程序的用法。

 例18-8 dexplorer程序。

dexplorer程序是一个对系统进行全面检测的工具。在默认情况下，这个程序每5秒钟对系统的某个方面采集一次数据。

下面就是数据的采集过程：

# dexplorer

Output dir will be the current dir (/export/home/root/DTrace/Dexplorer).

Hit enter for yes, or type path:

Starting dexplorer ver 0.70.

Sample interval is 5 seconds. Total run is > 100 seconds.

0% Interrupts by CPU...

5% Interrupt counts...

10% Dispatcher queue length by CPU...

15% Sdt counts...

20% Pages paged in by process name...

25% Files opened count...

30% Disk I/O size distribution by process name...

35% Minor faults by process name...

40% Vminfo data by process name...

45% Mib data by mib statistic...

50% TCP write bytes by process...

55% Sample process @ 1000 Hz...

60% Syscall count by process name...

65% Syscall count by syscall...

70% Read bytes by process name...

75% Write bytes by process name...

80% Sysinfo counts by process name...

85% New process counts with arguments...

90% Signal counts...

95% Syscall error counts...

100% Done.

File is de_duanf_200510271803.tar.gz

从开始的信息我们知道，这个运行的dexplorer版本现在是0.70。

在输出的最后，我们发现所采集的数据被存放到一个以tar.gz结尾的压缩文件中。

下面让我们来解开这个压缩文件：

# gunzip de_duanf_200510271803.tar.gz

# tar xf de_duanf_200510271803.tar

de_duanf_200510271803

de_duanf_200510271803/Cpu

de_duanf_200510271803/Cpu/interrupt_by_cpu

de_duanf_200510271803/Cpu/interrupt_time

de_duanf_200510271803/Cpu/dispqlen_by_cpu

de_duanf_200510271803/Cpu/sdt_count

de_duanf_200510271803/Disk

de_duanf_200510271803/Disk/pgpgin_by_processname

de_duanf_200510271803/Disk/fileopen_count

de_duanf_200510271803/Disk/sizedist_by_processname

de_duanf_200510271803/Mem

de_duanf_200510271803/Mem/minf_by_processname

de_duanf_200510271803/Mem/vminfo_by_processname

de_duanf_200510271803/Net

de_duanf_200510271803/Net/mib_data

de_duanf_200510271803/Net/tcpw_by_process

de_duanf_200510271803/Proc

de_duanf_200510271803/Proc/sample_process

de_duanf_200510271803/Proc/syscall_by_processname

de_duanf_200510271803/Proc/syscall_count

de_duanf_200510271803/Proc/readb_by_processname

de_duanf_200510271803/Proc/writeb_by_processname

de_duanf_200510271803/Proc/sysinfo_by_processname

de_duanf_200510271803/Proc/newprocess_count

de_duanf_200510271803/Proc/signal_count

de_duanf_200510271803/Proc/syscall_errors

de_duanf_200510271803/Info

de_duanf_200510271803/Info/uname-a

de_duanf_200510271803/Info/psrinfo-v

de_duanf_200510271803/Info/prtconf

de_duanf_200510271803/Info/df-k

de_duanf_200510271803/Info/ifconfig-a

de_duanf_200510271803/Info/ps-o

de_duanf_200510271803/Info/uptime

de_duanf_200510271803/log

这样，我们就会得到存储系统数据的文件。通过此文件可以好好分析系统的负载运行情况了。

如果不需要看采集数据的过程，可以将它们直接存放某个目录下，如/var/tmp：

# dexplorer -qy -d /var/tmp

#

其中，

 -qy：是不在屏幕上显示。

 -d：存放的路径。

dexplorer只是采集了系统概括信息，如果要仔细查看系统某一方面的信息，还可以用工具包中的其他程序。

 例18-9 使用isnoop来检测系统I/O情况。

# iosnoop

UID PID D BLOCK SIZE COMM PATHNAME

100 15795 R 3808 8192 tar /usr/bin/eject

100 15795 R 35904 6144 tar /usr/bin/eject

100 15795 R 39828 6144 tar /usr/bin/env

100 15795 R 3872 8192 tar /usr/bin/expr

100 15795 R 21120 7168 tar /usr/bin/expr

100 15795 R 43680 6144 tar /usr/bin/false

100 15795 R 44176 6144 tar /usr/bin/fdetach

100 15795 R 3920 8192 tar /usr/bin/fdformat

100 15795 R 3936 8192 tar /usr/bin/fdformat

100 15795 R 4080 8192 tar /usr/bin/fdformat

100 15795 R 9680 3072 tar /usr/bin/fdformat

输出的内容可比iostat命令的输出要详细多了。

还可以使用tcpnoop来查看新建立的tcp连接情况。

 例18-10 查看新建立的tcp连接情况。

# tcptop -C 10

Sampling... Please wait.

2005 Jul 5 04:55:25, load: 1.11, TCPin: 2 Kb, TCPout: 110 Kb



UID PID LADDR LPORT FADDR FPORT SIZE NAME

100 20876 192.168.1.5 36396 192.168.1.1 79 1160 finger

100 20875 192.168.1.5 36395 192.168.1.1 79 1160 finger

100 20878 192.168.1.5 36397 192.168.1.1 23 1303 telnet

100 20877 192.168.1.5 859 192.168.1.1 514 115712 rcp



2005 Jul 5 04:55:35, load: 1.10, TCPin: 0 Kb, TCPout: 0 Kb



UID PID LADDR LPORT FADDR FPORT SIZE NAME

0 242 192.168.1.5 79 192.168.1.1 54220 272 inetd

0 20879 192.168.1.5 79 192.168.1.1 54220 714 in.fingerd




[...]

上面的输出说明，系统每隔10秒种采集一次数据。如果不使用^C结束的话，屏幕将一直显示下去。从目前的输出可以看到，进程20877的输出流量最大为110KB。

如果只想简单地查看有哪些计算机连接到自己，使用connections程序就可以了。

 例18-11 查看连接自己的计算机。

# connections

UID PID CMD TYPE PORT IP_SOURCE

0 242 inetd tcp 79 192.168.1.1

0 359 sshd tcp 22 192.168.1.1

100 1532 Xorg tcp 6000 192.168.1.1

^C

 例18-12 使用prustat脚本显示进程的%CPU, %Mem, $Disk and %Net。

# prustat -t10 5

PID %CPU %Mem %Disk %Net COMM

22301 54.30 3.15 0.00 0.00 setiathome

440 2.24 45.36 0.00 0.00 Xsun

22272 30.26 0.31 0.00 0.00 perl

2618 0.26 14.34 0.00 0.00 mozilla-bin

582 1.27 2.16 0.00 0.00 gnome-terminal

576 0.02 2.80 0.00 0.00 nautilus

2299 0.21 1.99 0.00 0.00 acroread

578 0.35 1.46 0.00 0.00 gnome-panel

574 0.37 1.31 0.00 0.00 metacity

6504 0.00 1.23 0.00 0.00 nautilus-throbb

PID %CPU %Mem %Disk %Net COMM

22301 57.02 3.15 0.00 0.00 setiathome

440 2.35 45.36 0.00 0.00 Xsun

22272 26.99 0.31 0.00 0.00 perl

2618 0.26 14.34 0.00 0.00 mozilla-bin

22321 3.48 1.46 0.00 0.00 DTrace

582 1.29 2.16 0.00 0.00 gnome-terminal

576 0.02 2.80 0.00 0.00 nautilus

2299 0.21 1.99 0.00 0.00 acroread

578 0.36 1.46 0.00 0.00 gnome-panel

574 0.39 1.31 0.00 0.00 metacity

^C

从输出我们可以看出，系统有两个进程在争夺CPU资源，它们分别是setiathome和perl。由于输出数据的显示是分类的，Xsun在%Mem项比perl在%CPU项的数值大，所以Xsun被排到了第二位。“-t10”属性的意思是显示最大的10行，而“5”是每5秒钟来采集一次数据。

DTraceToolkit中有许多有用的工具，对于了解系统运行状况非常好用，有兴趣的读者不妨自己下载后运行一下，体验一下DTrace带来的方便和快捷。

对于某些读者来说，如果使用现成的脚本程序还不能满足自己的需求，那么，根据需要自己动手编写DTrace程序，写一个D程序也不是什么难事，事实上D语言也非常简单。由于介绍如何写D语言已经超出了本书的范围，所以推荐读者到Sun公司网站上看看，它有一个pdf文档可以帮助我们如何学习写D语言。在此只给出链接http://docs.sun.com/db/doc/817-6223，有需要的读者可以自行下载。

luren04

第19章 Solaris 10区域技术   
Solaris 10版本支持将一个主机用软件分成多个区域（zone），每个区域都是一个独立的系统，可以运行不同的软件或同样软件的不同版本。本章主要介绍区域（zone）技术。

luren04

19.1 Solaris 10区域介绍   
本节主要介绍区域的基本概念、特性，以及区域是如何工作的等。

19.1.1 概述
区域为运行中的应用程序提供一个隔离的安全环境。利用区域，你可以在一个Solaris实例中创建多个虚拟的操作系统环境。区域可使一个或多个进程与系统中其他进程分开独立运行。例如，某个区域中运行的进程只能将信号发送给同一区域中的其他进程，而不考虑其用户ID和其他证书信息。一旦发生错误，只会影响到运行在这一区域中的进程。

Solaris容器技术提供了一种创新的服务器虚拟化方案。由于操作系统的每个实例能够支持多个软件分区，因此Solaris容器使整合变得十分简单而安全。Solaris容器能够根据业务目标在容器内或跨容器动态地调整资源，从而提供更好的计算资源利用率。由于系统开销极小（不到1%），所以它能用于在每个系统或动态系统域中创建超过8 000个容器。同时，应用程序不仅实现了相互隔离，而且与系统故障隔离，因此一个应用程序出现问题不会影响其他应用程序。

通过使用Instant Restart，每个Solaris容器只需几秒钟即可重新启动，从而更大限度地减少应用停机时间。

由于Solaris容器完全由软件支持，与平台无关，因此可以在SPARC或基于x86的64位平台上使用，包括大规模的服务器及刀片服务器。Solaris容器还利用了Solaris的资源管理功能，允许在容器之间动态转移资源，可确保更高的利用率。

1．全局区域概括介绍
与先前的Solaris OS发行版一样，每个Solaris 10系统都包含一个通用全局环境，称为全局区域。全局区域具有以下两种功能：它是系统的默认区域，可用于整个系统的管理控制。如果全局管理员没有创建非全局区域（可简称为区域），则所有进程将运行在全局区域中。

只能从全局区域配置、安装、管理或卸载非全局区域。只有全局区域才可从系统硬件进行引导。只有在全局区域中才具有管理功能，例如物理设备、路由选定或动态重新配置（DR）。运行在全局区域中的具有适当特权的进程能够访问与其他区域相关联的对象。

对于非全局区域中具有特权的进程或用户来说是不允许的操作，全局区域中的非特权进程或用户也许可以执行。例如全局区域中的用户可以查看关于系统中每个进程的信息。在维护整体系统安全时，管理员可以为区域赋予一部分管理功能。

2．非全局区域概括介绍
非全局区域不需要专用CPU、物理设备或物理内存。在单个域或系统中运行的多个区域可以共享这些资源。某些区域的引导和重新引导不会影响到系统中的其他区域。每个区域都可提供一组自定义的服务。为增强基本进程隔离，一个进程只能“看见”或发信号给处于同一区域中的其他进程。区域之间的基础通信是通过赋予每个区域至少一个逻辑网络接口来实现的。即使不同数据包流通过同一个物理接口传送，运行在一个区域中的应用程序也无法看到另一区域中的网络流量。

需要网络连接的每个区域都配置了一个或多个专用IP地址。

19.1.2 区域是如何工作的
对于合并许多应用程序到一个服务器上来说，区域是一个很好的工具。以前，一般需要很多台服务器的事情现在一台就解决了，减少了很多管理成本。

图19-1中一个服务器上有四个区域，每个区域都有自己的应用程序、用户。它们互不干扰地工作在各自的区域，并且有一个共同的硬件环境。从图例中还可以看出，不同版本的应用软件也可以工作在不同的区域。区域也可以为每个服务定制不同的软件环境。

图示最下面的部分是描述物理硬件部分，这里有网卡和存储磁盘等。再往上一层就是系统核心服务部分、远程管理和硬件管理部分。这两层构成了所有区域都共同拥有的基础平台。再往上的第三层的zone management就是全局区域所独有的、管理区域的工具了。第四层是被称为虚拟平台的部分。在全局的文件系统上，又建立起三个虚拟的文件系统，它们有相同的目录结构。在非全局区域看来，虚拟文件系统就是本区域的文件系统。其实，不同区域的目录有些是共用的。第五层就是应用程序层了。这里有不同的应用程序，它们在一个物理计算机上互不干扰地运行着。最上边的一层就是全局区域，其实，我们可以将全局区域看做是其他三个非全局区域的容器。

总结一下，区域是如何工作的：

 不同版本的软件可以装在不同的区域。

 每个区有自己的网络连接和IP地址。

 同区的进程间可以通信，不同区的只能通过网络通信。

 每个系统的容器是global zone，global zone有双重的属性，默认的区和管理控制区。

 全局区可以安装、设置、管理、卸载分全局区。但只有全局区管理系统的硬件和路由，并且特权进程可以联系到分全局区。

图19-1 多区域结构示意图

 全局区的用户可以查看整个系统的进程信息。

 每个区都有自己的名字，包括全局区，全局区的名字就叫global，每个区都有id号，全局区的id号是0。

1．全局区和非全局区域对比
全局区域和非全局区域对比如表19-1所示。

表19-1 全局区域和非全局区域

全局区域
非全局区域

ID为0
当分区启动时得到系统ID

当系统启动时提供了一个实例（instance）
当全局区启动后分享系统内核

包含完整安装版的Solaris软件包
是Solaris操作系统软件包的子集

包含很多的软件包和应用软件
可以和全局区分享软件包

提供了完整的产品信息数据库
可以有自己的软件包且不与全局区分享

保存了全局区的设置信息
可以不通过全局区而自己安装软件包

它是明确知道所有的设备和文件系统的
提供的产品信息数据库信息包括本区的和从全局区分享的

它是惟一知道非全局区的存在和设置的区
它不知道其他区的存在

它是惟一可以设置、安装、管理、卸载的区
不能安装、管理、卸载区，包括它自己


3．非全局区域的状态
 Configured

设置状态。

 Incomplete

当在安装或卸载的时候，zoneadm设置目标区的状态为incomplete。

 Installed

分区正处在安装状态，zoneadm校验系统软件包的设置。

 Ready

分区的虚拟平台已经建立，内核创建了zsched进程，网络端口启用，文件系统已经mount，设备已经被设置好，惟一的区别是ID号已经被系统分发。但是，与分区相关的进程还没有开始。

 Running

用户的进程和区的应用环境都运行着。

 Shutting down and Down

Shutting down表明关机器电源；Down表明关闭非全局区。

19.1.3 非全局区域的特性总结
 Security

一个放置在分区的进程不同于全局区，这个进程只能有本分区改变。网络服务也可以放在分区中，分区可以隔绝服务的故障所带来的损害。入侵者进入分区后，就被限制在这个区内。不影响其他区。区的权限是系统全局权限的子集。

 Isolation

允许在一台计算机上有多个应用程序，这些应用程序共享资源。比如，一个应用可以在不同的分区，而使用网络端口是相同的，这样可以配不同的IP地址，防止这个应用软件在一个区内的干扰。

 Virtualization

分区隐藏了系统的硬件设备、系统主要的IP地址和主机名。这些环境维持着多个分区。活动分区的管理者不能重新启动。

 Granularity

分区不需要专门的硬件设备；

分区能定制服务；

分区是整个系统文件的一部分；

分区的naming services是不同的。

 Environment

分区不能更改硬件环境。