应用错误收集

我最近一直在使用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 USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
  8379 was      3208M 2773M cpu5    60    0   5:29:13  19% java/145
  7123 was      3159M 2756M run     59    0   5:26:45 7.7% java/109
  5855 app1     1132M   26M cpu2    60    0   0:01:01 7.7% java/18
 16503 monitor   494M  286M run     59   19   1:01:08 7.1% java/106
  7112 oracle     15G   15G run     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 run     58    0   0:00:09 4.0% oracle/1
  7155 oracle     96M 6336K cpu1    60    0   0:00:07 3.6% oracle/1
...
Total: 495 processes, 4581 lwps, load averages: 74.79, 35.35, 23.8

prstat -m 1 1（几秒钟后）

   PID USERNAME 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
...
Total: 497 processes, 4576 lwps, load averages: 88.86, 39.93, 25.51

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

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

欢迎任何解释！

CU，Joe

Solaris上prstat -m的已知问题就是计算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用户锁。其中一个java进程的plockstat和/或简单的dtrace概要分析会很有帮助。

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

1 个答案: