罗马2全面战争信誉:prstat：系统进程监控

Solaris 中最重要、使用最广的实用工具是 prstat（参见 prstat(1)）。prstat 可以快速回答以下问题：

• 系统占用了多少 CPU 和内存？

• 系统效用了哪些进程（或用户、 zone 、项目、任务）？

• 系统怎样使用进程/线程（用户绑定，I/O 绑定）？

在最简单的形式中，prstat （即 prstat 2）将检测所有进程并根据 CPU 使用率报告数据。

prstat – prstat 2 按照 CPU 使用率的顺序报告所有进程

正如截屏中看到的，进程的顺序根据当前的 CPU 使用率从高（最多）到低（最少）排列（% - 100% 表示所有系统 CPU 都完全利用）。对于列表中的每个进程，将打印以下信息：

• PID：进程的进程 ID。

• USERNAME：真实用户（登录）名称或真实用户 ID。

• SIZE：进程的总虚拟内存大小，以 K、M 或 G 为单位。

• RSS：进程的驻留集大小 (RSS)，以 K、M 或 G 为单位。

• STATE：进程的状态 (cpuN/sleep/wait/run/zombie/stop)。

• PRI：进程的优先级。数字更大表示优先级更高。

• NICE：优先级计算中使用的 nice 值。只有特定调度类中的进程才有 nice 值。

• TIME：进程的累计执行时间。

• CPU：进程使用的当前 CPU 时间的百分比。如果在非全局域中执行并且池设备是活动的，百分比将是 zone 绑定的池所使用的处理器集合中处理器的百分比。

• PROCESS：进程的名称（执行文件的名称）。

• NLWP：进程中 lwps 的数量。

prstat 的 参数是采样/刷新的时间间隔（以秒为单位）。

专题报告 – 排序

除了 CPU 使用率之外，prstat 输出还可以按照其他指标排序。可以将 -s（降序）或 -S（升序）与指标选项一起使用（即 prstat -s time 2）：

标准

注释

cpu

按照 CPU 使用率排序。这是默认设置。

pri

按照进程优先级排序。

rss

按照驻留集大小排序。

size

按照进程图像排序。

time

按照进程执行时间排序。

专题报告 – 连续模式

对 prstat 使用选项 -c，新的报告将打印在上一个报告的下方，而不是覆盖它。这在收集文件信息时非常有用（即 prstat -c 2 > prstat.txt）。选项 -n 可以用来设置报告的最大长度。

prstat – 按照 CPU 使用率升序进行连续报告排序

专题报告 – 用户

对 prstat 使用 -a 或 -t 选项，将额外打印有关用户的报告。

prstat – 用户的 prstat -a 2 报告

专题报告 – zone

对 prstat 使用 -Z 选项，将额外打印有关 zone 的报告。

专题报告 – 项目（参见 projects(1)）

对 prstat 使用 -J 选项，将额外打印有关项目的报告。

prstat – 有关项目的 prstat -J 2 报告

专题报告 – 任务（参见 newtask(1)）

对 prstat 使用 -T 选项，将额外打印有关任务的报告。

prstat – 任务的 prstat -T 2 报告

专题报告 – Microstate Accounting

与其他每个时间周期或每个固定时间间隔（通常为百分之几秒）收集 CPU 数据的操作系统不同，Solaris 10 合并了一种名为 Microstate Accounting 的技术，可以使用高分辨率时间戳测量每个时间的 CPU 数据，从而生成更为准确的数据统计。

Microstate Accounting 系统为线程和 CPU 维护准确的时间计数器。基于线程的 Microstate Accounting 跟踪每个线程中几个有意义的状态，以及用户和系统时间，包括陷阱时间、锁定时间、睡眠时间和等待时间。prstat 按进程（选项 -m）或线程（选项 -mL）报告微观状态。

prstat – prstat -m 2 报告进程微观状态

上面的屏幕输出展示了运行系统的微观状态。查看最上面 PID 693 那一行，可以发现，进程 Xorg 在 userland 上花费的时间占总时间的 1.8%，而其他时间的 (98%) 都在休眠。prstat – prstat -mL 2：

上面的屏幕输出展示了运行系统每个线程的微观状态。查看 PID 1311 那一行（屏幕中间），可以看到进程 firefox-bin 的 LWP #9 和 LWP #8 微观状态。

prstat 使用场景 – cpu 时延问题

测量 CPU 饱和度的一个重要方法是 prstat 的时延问题（LAT 列）输出。我们再次使用两个 CPU 密集型应用程序副本（cc_usr）。

prstat – 使用 CPU 密集型应用程序观察时延问题

现在运行 prstat Microstate Accounting 报告，即 prstat -m 2 并记录输出：

prstat – prstat -m 2 输出

请观察最上面两行输出 PID 2223 和 PID 2224。可以清楚地看到两个流程的 LAT 微观状态（CPU 时延问题）都有较高的时间百分比（分别是 50% 和 52%）。其余时间如期花费在消耗方面（USR 微观状态）。此例清楚的表明，CPU 绑定应用程序争夺测试系统中惟一的一个 CPU，导致为访问 CPU 需要很长的等待时间（时延问题）。

prstat 使用场景 – 高系统时间

现在运行系统调用集中型应用程序（cc_sys）并观察 prstat 的输出。首先，启动一个 cc_sys 实例：

prstat – 系统调用集中型应用程序

然后观察 prstat -m 2 输出：

prstat – prstat -m 2，系统调用集中型应用程序的输出

注意最上方 PID 2310 那一行。清楚地发现流程 cc_sys 占用了高系统时间使用率 (61%)。还可以发现 ICX/VCX (277/22) 的比率很高，这说明该进程经常无意识关闭 CPU。

prstat 使用常见 – 过度锁定

经常可以看到，多处理器系统上应用程序的扩展性很差。根本原因之一可能在于，应用程序中的锁定设计很差，导致在同步时的等待时间过长。prstat 列 LCK 报告等待用户锁定花费的时间。

我们看一个示例，一个示例程序实现了关键段的锁定机制，使用的是读/写锁定。该程序有 4 个线程需要访问共享的关键 zone 以进行读取，还有一个线程以写模式访问关键段。为了说明问题所在，有意减慢了写入器的速度，以便它会占用关键段一段时间（对于读取器这是有效的障碍）。

首先启动程序，比如写入器在关键段中花费了 0 毫秒（理想情况）。

cc_lck 0 – 在理想情况下运行

现在观察每个线程的微观状态。使用 prstat -mL -p 2626 2。

cc_lck 0 – prstat 输出

可以看到，所有 5 个线程几乎争夺到了相等的计算机资源。因为不管是读取器还是写入器都没有占用关键段很长的时间，没有记录等待时间。

现在重新执行整个测试，写入器将等待 10 毫秒。

现在再次观察微观状态。使用 prstat -mL -p 2656 2。

cc_lck 10 – prstat 输出

这次情况似乎不太一样了。有 4 个线程在等待关键段的锁定期间花费的时间占总时间的 84%。另一方面，写入器 (LWP #1) 有 (82%) 的时间在休眠。

在本例的应用程序中，如果查看源代码会发现存在明显的锁定问题，prstat Microstate Accounting 功能将帮助找出较大程序的锁定弱点。