我最近一直在使用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
答案 0 :(得分:4)
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概要分析会很有帮助。