在 Solaris 上解释 prstat 与 'prstat -m' 的差异

Question

我最近一直在使用 prstat 和 prstat -ma 来调查性能问题，我想我已经基本了解了 Solaris 10 中采样与微状态会计的差异。所以我不希望两者总是显示完全相同数字。

今天我遇到了一个场合，其中 2 显示出如此不同的输出，我在解释它们和理解输出时遇到了问题。这台机器是一个负载很重的 8-CPU Solaris 10，有几个大型 WebSphere 进程和一个 Oracle 数据库。今天系统实际上停止了大约 15 分钟（平均负载 >700）。我很难获得任何 prstat 信息，但能够从“prtstat 1 1”和“prtstat -m 1 1”中获得一些输出，这些输出很快一个接一个地发布。

输出的顶行：

prstat 1 1：

    PID 用户名大小 RSS 状态 PRI NICE 时间 CPU 进程/NLWP
  8379 是 3208M 2773M cpu5 60 0 5:29:13 19% java/145
  7123 是 3159M 2756M 运行 59 0 5:26:45 7.7% java/109
  5855 app1 1132M 26M cpu2 60 0 0:01:01 7.7% java/18
 16503 监视器 494M 286M 运行 59 19 1:01:08 7.1% java/106
  7112 oracle 15G 15G 运行 59 0 0:00:10 4.5% oracle/1
  7124 oracle 15G 15G cpu3 60 0 0:00:10 4.5% oracle/1
  7087 app1 15G 15G 运行 58 0 0:00:09 4.0% oracle/1
  7155 oracle 96M 6336K cpu1 60 0 0:00:07 3.6% oracle/1
...
总计：495 个进程，4581 lwps，平均负载：74.79、35.35、23.8

prstat -m 1 1（几秒钟后）

   PID 用户名 USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/NLWP  
  7087 app1 0.1 56 0.0 0.2 0.4 0.0 13 30 96 2 33 0 oracle/1
  7153 oracle 0.1 53 0.0 3.2 1.1 0.0 1.0 42 82 0 14 0 oracle/1
  7124 oracle 0.1 47 0.0 0.2 0.2 0.0 0.0 52 77 2 16 0 oracle/1
  7112 oracle 0.1 47 0.0 0.4 0.1 0.0 0.0 52 79 1 16 0 oracle/1
  7259 oracle 0.1 45 9.4 0.0 0.3 0.0 0.1 45 71 2 32 0 oracle/1
  7155 oracle 0.0 42 11 0.0 0.5 0.0 0.1 46 90 1 9 0 oracle/1
  7261 oracle 0.0 37 9.5 0.0 0.3 0.0 0.0 53 61 1 17 0 oracle/1
  7284 oracle 0.0 32 5.9 0.0 0.2 0.0 0.1 62 53 1 21 0 oracle/1
...
总计：497 个进程，4576 lwps，平均负载：88.86、39.93、25.51

我很难解释输出。prstat 似乎告诉我，正如我在正常情况下所期望的那样，正在进行大量的 Java 处理，以及一些 Oracle 的东西。prtstat -m 显示完全由 Oracle 控制的机器，消耗大量系统时间，并且整体 CPU 严重过载（LAT 中的大量数字）。

我倾向于相信 prstat -m 的输出，因为这与系统在此期间的感觉更加匹配。完全迟钝，几乎不再有来自 WebSphere 等的用户请求处理。但是为什么 prstat 会显示出如此严重的不同数字？

欢迎对此进行任何解释！

CU，乔

Answer 1

prstat -m在 Solaris 上计算 cpu 使用数据的方式存在一个已知问题- 您看到的值是进程中所有线程 (LWP) 的平均值，因此对于大量多线程的进程来说太低了 - 例如您的 Java 应用程序服务器，每个服务器可以有数百个线程（请参阅您的 NLWP）。其中不到十几个可能是 CPU 猪，因此 java 的 CPU 使用率看起来“低”。您需要调用它prstat -Lm以获取每个 LWP（线程）细分以查看该效果。参考：

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6780169

如果没有进一步的性能监控数据，就很难对您在那里看到的内容做出非推测性的解释。我假设 java 中的锁争用。一种可能导致这种情况的特定工作负载是大量多线程内存映射 I/O，它们都会堆积在进程地址空间锁上。但它当然可能是一个纯粹的 Java 用户端锁。阿plockstat对java方法中的一种，和/或简单的DTrace分析将是有益的。