Интерпретировать различия в prstat vs. 'prstat -m' on Solaris

Question

Я использовал prstat и prstat -ma для изучения проблем производительности в последнее время, и я думаю, что я в основном понял различия в выборке и учете в штате микросостояния в Solaris 10. Поэтому я не ожидаю, что оба всегда будут показывать точно такое же число.

Сегодня я столкнулся с ситуацией, когда 2 показали очень разные результаты, что у меня проблемы с их интерпретацией и пониманием результата. Машина представляет собой сильно загруженный 8-процессорный 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, потребляя огромное количество системного времени, а общий процессор сильно перегружен (большие числа в LAT).

Я склонен верить выводам prstat -m, потому что это близко соответствует тому, что чувствовала система в течение этого времени. Полностью вялая, почти не обработка запросов пользователя от WebSphere и т. Д. Но почему prstat будет показывать столь сильно отличающиеся числа?

Любые объяснения этого приветствуются!

CU, Джо

Answer 1

Там известная проблема с prstat -m на Solaris в пути процессоре показатели использования рассчитывается - значение, которое вы видите его усреднение по всем потокам (LWP,) в процессе, и, следовательно, далеко далеко слишком мало для многопоточных процессов, таких как серверы приложений Java, которые могут иметь сотни потоков каждый (см. ваш NLWP). Менее дюжины из них, вероятно, являются процессорами, поэтому использование процессора java выглядит «низким». Вам нужно будет позвонить ему с prstat -Lm, чтобы получить разбивку по каждому LWP (потоку), чтобы увидеть этот эффект. Справка:

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

Без данных мониторинга производительности дополнительно трудно дать неспекулятивное объяснение того, что вы видели там. Я предполагаю, что блокирование противоречит внутри java. Одна конкретная рабочая нагрузка, которая может привести к этому, - это многопоточность ввода/вывода с отображением многопоточной памяти, все они будут накапливаться в блокировке адресного пространства процесса. Но это может быть чисто java userside. A plockstat на одном из процессов java и/или простое профилирование dtrace было бы полезно.