Исследование высокой загрузки ЦП для процессов JAVA в Linux / AIX / HPUX / Solaris / Windows

Это процесс изучения использования ЦП для сервера приложений JAVA ™ в ответ на необходимость решения проблемы производительности или определения базовой линии для приложения. В частности, это исследование относится к AIX, Linux, Solaris, HPUX, UNIX®-подобным системам и Windows. Это раскроет количество ресурсов процессора, о которых сообщалось об использовании, количество доступных процессоров, используемых каждым процессом, и количество процессоров, используемых потоками в процессах. Мы очень часто используем этот процесс в WebSphere Application Server Support, но он не ограничивается этим использованием или даже WebSphere Application Server. Это исследование не сравнивает использование ЦП между аппаратными платформами, но может быть полезным в качестве части этих расследований.

Я расскажу о процессе, используемом общедоступными инструментами, чтобы сделать его более универсальным. Те, в средах с полностью интегрированным мониторингом производительности, могут видеть, что происходит внутри инструментов мониторинга производительности.

3 цели, представляющие интерес для расследований ЦП, заключаются в том, чтобы найти:

а) Какое использование процессора сервера / платформы и является ли это узким местом?

б) если есть проблема с использованием процессора - какие приложения и процессы используют процессор и какие потоки в процессах используют процессор.

c) если есть одно или несколько приложений JAVA, использующих процессор, - какие потоки Java соответствуют потокам, использующим процессор.

Первое правило исследования производительности: вы должны собирать информацию во время возникновения проблемы.

Основные понятия, используемые в этом блоге:

Нам нужно будет договориться о некоторой терминологии. Серверы приложений JAVA работают как процессы в операционных системах компьютера (ОС). Могут быть и другие имена процессов (сервисы, демоны и т. Д.), Но я буду называть их процессами или идентификаторами процессов (идентификаторы процессов). Определяющими характеристиками процесса является то, что он имеет свою собственную память, он запускается ОС и взаимодействует с ним.

ОС предоставляет базовые функции, такие как доступ к файлам, распределение времени, сетевые коммуникации и межпроцессное взаимодействие, а также выполнение некоторого набора команд.

Процессы в целом имеют возможность порождать другие процессы и связываться с ними для выполнения задач их выполнения. Это не очень распространено на серверах приложений Java, но возможно. Каждый процесс обычно создает потоки или легковесные процессы (tid, lwp или lwpid), которые фактически реализуются операционной системой.

Потоки не имеют собственной памяти, но совместно используют доступ к памяти процесса, который их породил. Потоки являются артефактом ОС, и каждая ОС будет предоставлять некоторые инструменты для отображения состояния процессов и потоков в любой момент времени. Серверы приложений JAVA фактически расширяют концепцию и реализацию потоков и предоставляют собственные имена для потоков, но эти потоки JAVA по-прежнему зависят от выполняемых потоков ОС. Серверы приложений JAVA также расширяют функциональность потоков с пулами, параллелизмом и так далее. Это усложняет шаг c в большинстве случаев, когда вам нужно согласовать идентификаторы потоков JAVA с идентификаторами потоков ОС.

Краткое содержание расследования:

Хитрость, конечно, заключается в том, чтобы найти правильные инструменты и уметь связывать информацию. Итак, первая задача состоит в том, чтобы найти инструмент, который позволяет процессору использовать как процессы, так и pids, и потоки (обычно помеченные как lwp, lwpid или tids). Конечно, есть много инструментов, поскольку мы говорим о серверных ОС, top на linux, topas в AIX, nmon на нескольких платформах, glance на HPUX, pslist в Windows, prstat на Solaris и так далее.

Этот блог будет использовать инструменты Linux для иллюстрации процесса. Чтобы облегчить (человеческий) процесс расследования, лучше всего использовать инструменты, которые являются универсально доступными, если это вообще возможно, и знать о более сложных инструментах, которые можно использовать.

Одним из важных замечаний является то, что, как правило, рекомендуется использовать инструменты, которые обеспечивают вывод в электронном виде для последующего анализа, и взаимодействовать с другими экспертами в данной области. Следствием является предоставление меток времени, если в инструменте их нет. Для шага C ниже, это фактически требование. Конечно, также требуется, чтобы инструменты обеспечивали понятный вывод. Я рекомендую обратиться к справочным страницам linux / AIX / HPUX / Solaris, онлайн-документации и всем без исключения руководствам, чтобы получить больше информации об инструментах в каждой среде.

Шаг А: у нас есть высокий процессор?

Итак, чтобы проиллюстрировать исследование на платформах, подобных Linux или UNIX, vmstat довольно универсально доступен. Также легко вызывать и захватывать с незначительными раздражениями. Поэтому на иллюстрации будет использоваться vmstat для иллюстрации определения общего использования ЦП на уровне ОС.

Типичный вызов vmstat 1 1000 или около того, но vmstat 1 3 используется для краткости

Итак, чтобы получить метку времени и информацию о производительности:

date> .tmp / testit

vmstat 1 3 >> / tmp / testit

и файл / tmp / testit будет показывать что-то вроде:

Ср 20 мая 12:24:11 ПО ВОСТОЧНОМУ ВРЕМЕНИ 2015

*** вмстать начало

rb swpd свободный буферный кеш si so bi bo in cs us sy id wa st 8 0 372928 814108 267144 15614812 0 0 294 7347 6199 7325 67 4 29 0 0 11 0 372928 813892 267144 15614940 0 0 0 152 7746 3213 99 1 0 0 0 8 0 372928 814156 267144 15615148 0 0 0 38 7466 2740 99 1 0 0 0

Просто для того, чтобы достичь максимума, первая строка данных является кумулятивной с момента последней перезагрузки, а следующие строки - с интервалом в 1 секунду. Числа под заголовком id * (cpu idle%) представляют интерес. Поскольку это показывает, что процессор простаивает на 0%, процессор фактически очень занят в эти 2 секунды.

Конечно, временной интервал может быть указан для vmstat, и выходные данные, как правило, будут намного более плавными для выбранных более длинных интервалов. Просто глядя на этот вывод, мы можем иметь реальное узкое место процессора в системе.

Часто обсуждаемый вопрос - насколько допустимо использование процессора. Это можно рассматривать как предположение о том, что использование процессора более чем на 50% является проблемой. Исторически сложилось так, что 80% занятых (или 20% бездействующих) было практическим правилом для систем, поддерживающих интерактивные приложения. Это следует изучить в вашей среде, поскольку у вас может быть очень хороший отклик при более высоком использовании ЦП или у вас могут быть другие проблемы или бизнес-цели, которые требуют какого-либо другого использования ЦП.

Если это было расследование проблемы с производительностью, и vmstat последовательно регистрировал это:

procs ----------- память ---------- --- своп-- ----- io ---- - система-- ----- процессор ----- rb swpd свободный буферный кеш si so bi bo in cs us sy id wa st 2 0 8 266056 130176 1352704 0 0 294 35 665 1552 8 4 86 2 0 1 0 8 264356 130216 1354632 0 0 0 184 1958 2605 1 4 93 2 0 0 0 8 264248 130216 1354660 0 0 0 0 781 1364 1 1 99 0 0

Расследование по поводу высокой загрузки ЦП было бы практически закончено, потому что ЦП простаивает. Это может ускорить процесс учета ЦП в случае, если это строго для решения проблем времени отклика. Аналогично, если мы видим, что на самом деле под заголовком si и т. Д. Есть двузначные или большие числа (или sr в Solaris), у нас возникает проблема с памятью. Swap in (si) и Swap out (so) указывают, что операционная система действительно записывает память приложения на диск и считывает ее обратно для обработки, что приведет к снижению производительности. Так что это также указывает на то, что расследование обнаружило возможную проблему с производительностью.

Вы должны знать о двух возможных осложнениях:

Некоторое программное обеспечение для виртуализации может повлиять на использование ЦП, о котором сообщалось, и потребовать использования специальных инструментов. Это очень зависит от платформы, и рекомендуется обсудить это с соответствующими группами поддержки в вашей организации.

Многие системные администраторы отслеживают использование процессора, диска и памяти. Отчеты для этой установки могут не соответствовать используемому вами процессору. Вероятно, это связано с периодом выборки. С интервалами в одну секунду будут получены данные об использовании ЦП, которые необходимо будет усреднить для получения чисел, отслеживаемых системными администраторами.

Поскольку теперь у нас есть законные проблемы с использованием процессора, начиная с первого примера вывода vmstat, и нет никаких грязных признаков проблем с памятью, мы должны перейти к шагу B.

Шаг B: Какие процессы используют процессор?

Шаг B исследование Linux полностью возможно с помощью команды ps. Еще раз просмотрите страницы man / help для вашей среды и проконсультируйтесь с местными экспертами по предметным вопросам.

Существуют различные инструменты между ОС и даже реализациями на Linux и других UNIX-подобных системах. Обычная практика использования ps (в Linux или UNIX-подобных ОС) - использовать что-то вроде ps aux или ps -ef, чтобы увидеть длинный список свойств pid. Хотя это предоставляет много информации и является хорошим инструментом для отслеживания использования процессора pid в течение продолжительного времени, может быть утомительно понимать и находить высокое использование процессора с расширенными списками свойств. Чтобы сохранить этот блог простым, мы будем использовать следующую команду, которая даст нам хороший список процессов, user, cpu% и командной строки. Для записи ps - это моментальный снимок времени, и этот пример очень сильно упрощен по сравнению с обычными командами ps aux и аналогичными.

ps -eo pid, пользователь, pcpu, команда --sort = -pcpu

PID USER% CPU COMMAND
15102 root 60.1 / opt / ibm / WebSphere / AppServer / java / bin / java ... (полная команда усекается)
3297 root 0.1 BESClient
3445 root 0.1 Xorg
16200 root 0.1 packagekitd

Таким образом, в эту конкретную секунду у нас есть Java-процесс, который работает на сервере приложений WebSphere, который потребляет процессор, поэтому мы переходим к шагу C.

Примечание: я ожидаю, что кто-то прокомментирует, что top / nmon / glance / perfmon делает шаги A и B по существу тривиальными. Есть много полезных инструментов, но, пожалуйста, убедитесь, что вывод понятен. Некоторые из этих инструментов будут сообщать об общем использовании процессора, в то время как другие сообщат об общем количестве процессоров на сервере, а затем предоставят процент процессоров для каждого процесса на основе одного процессора. Это часто настраивается, но должно быть понято при анализе. Это будет немедленно распознано, если указанный процент процессорного времени> 100% для процесса или thred, но может вводить в заблуждение, если вы видите 50 потоков с использованием процессора 20%. Комментарий по поводу интервалов выборки по-прежнему актуален для обсуждений с системными администраторами.

Шаг C (часть 1): Идентификация подозрительных потоков:

Ключом к корреляции потоков Java с потреблением процессора является печать списков потоков с метками времени с системными идентификаторами и потреблением процессора, а также одновременное создание серии потоков (Oracle и аналогичных JAVA) или javacores (IBM JAVA).

Три javacores / threaddumps, взятые на расстоянии в одну минуту, являются хорошей отправной точкой. Потоки или javacores будут соотноситься с информацией о потоке системы. Например, команда ps для linux для печати только идентификаторов потоков и процессоров для процесса: ps -Lp <pid>. Вы также можете использовать top -h для печати списка или pslist в Windows и так далее.

Какой бы инструмент ни использовался, важно, чтобы отчет об использовании системного процессора создавался одновременно с созданием потоковых дампов / javacores.

Для некоторых инструментов отчет будет включать в себя идентификатор потока Java в качестве команды, и расследование почти закончено. Что хорошо видно в выбранном примере. Если в нескольких отчетах у главного потребителя процессора есть имя GC Slave, проблема, скорее всего, связана с размером кучи, или, если имя - JIT-компиляция, это тоже подсказка. В следующем примере - TIME - это действительно процессорное время, все строки предназначены для потоков, запущенных в процессе JAVA, и GC явно показывает основное потребление процессора. Даже с такого рода отчетами, возможно, стоит продолжить со спецификой Java.

PID LWP TTY TIME CMD
15102 15102 баллов / 0 00:00:00 Java
15102 15103 pts / 0 00:00:06 P = 713139: O = 0: CT
15102 15105 баллов / 0 00:00:00 Signal Reporter
15102 15106 pts / 0 00:00:07 Компиляция JIT
15102 15107 pts / 0 00:00:04 Компиляция JIT
15102 15108 pts / 0 00:00:01 JIT Компиляция
15102 15109 pts / 0 00:00:00 JIT Компиляция
15102 15110 баллов / 0 00:00:01 JIT Sampler
15102 15111 баллов / 0 00:00:00 JIT IProfiler
15102 15112 баллов / 0 00:00:00 Отправка сигнала
15102 15113 баллов / 0 00:00:00 Финализатор масте
15102 15114 баллов / 0 00:00:55 Concurrent Mark
15102 15115 баллов / 0 00:11:00 GC Slave
15102 15116 баллов / 0 00:00:60 GC Slave
15102 15117 баллов / 0 00:20:00 GC Slave
15102 15118 баллов / 0 00:40:00 GC Slave
15102 15119 баллов / 0 00:00:00 GC Slave
15102 15120 баллов / 0 00:00:00 GC Slave

Чтобы сделать шаг C более интересным, мы продолжим что-то вроде этого верхнего вывода в качестве примера потоков, использующих процессор

PID USER PR NI VIRT RES SHR S% CPU% MEM TIME + КОМАНДА 9226 wsusr 20 0 4681 м 1,1 г 97 м R 72,9 4,1 677: 02,58 Mthread-100 9452 wsusr 20 0 4681 м 1,1 г 97 м R 61,4 4,1 677: 52,61 Mthread-120 3055 wsusr 20 0 4681 м 1,1 г 97 м R 61,4 4,1 677: 23,43 Mthread-22 9071 wsusr 20 0 4681 м 1,1 г 97 м R 59,5 4,1 676: 13,21 Mthread-11 7635 WSUSR 20 0 4681 м 1,1 г 97 м R 55,7 4,1 676: 35,99 Mthread-118 7482 wsusr 20 0 4681 м 1,1 г 97 м R 46,1 4,1 678: 04,88 Mthread-14 24314 wsusr 20 0 4681 м 1,1 г 97 м R 46,1 4,1 674: 49,57 Mthread-88 310 wsusr 20 0 4681 м 1,1 г 97 м S 3,8 4,1 5: 04,98

Вы заметите, что% процессора превышает 100%, поэтому проверка должна начинаться с верхней части отчета, чтобы убедиться, что использование процессора является проблемой.

Вы также должны знать, что этот конкретный отчет выполняется для одного pid, и заголовок pid должен фактически содержать TID, поскольку это идентификаторы потоков.

Шаг C (часть 2): Поиск потоков Java:

Отказ от ответственности: в данном исследовании ничего не относится к WebSphere Application Server, и до этого этапа JAVA не был специфичным. За расследованием можно следить за любым процессом JAVA.

Javacores являются специфическими для IBM JRE, которые требуются в некоторых версиях WebSphere Application Server. IBM JRE могут использоваться взаимозаменяемо с другими JRE, и у нас есть некоторые расширения, и мы рекомендуем вам загрузить JRE и использовать их из комплектов разработчика IBM http://www.ibm.com/developerworks/java/jdk

Threaddumps и Javacores:

Threaddump довольно понятен - он распечатывает состояние каждого потока на сервере процессов на момент печати потока. Threaddumps - это артефакт стандарта Java, созданный в Oracle, OpenJDK и других дистрибутивах JAVA. Для сервера приложений WebSphere на платформах Solaris и HPUX дампы потоков обычно находятся в native_stdout.log для полного профиля или в console.log для профиля Liberty. Пример фрагмента threaddump из профиля Liberty с запущенным OpenJDK, показывающий первые две строки и первый поток:

2015-04-22 12:11:44

Полный дамп потока Виртуальная 64-битная серверная виртуальная машина OpenJDK (смешанный режим 24.75-b04):

Демон "Inbound Read Selector.1" prio = 10 tid = 0x00007fed40021000 nid = 0x401f runnable [0x00007fed54612000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait (собственный метод)
в sun.nio.ch.EPollArrayWrapper.poll (EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect (EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect (SelectorImpl.java:87)
- заблокировано <0x00000000d6fa26b0> (sun.nio.ch.Util $ 2)
- заблокирован <0x00000000d6fa26a0> (a java.util.Collections $ UnmodifiableSet)
- заблокировано <0x00000000d6fa2568> (sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select (SelectorImpl.java:98)
на com.ibm.ws.tcpchannel.internal.ChannelSelector.run (ChannelSelector.java:144)
на java.lang.Thread.run (Thread.java:745)

--- следуют аналогичные строки для каждого потока.

Javacore - это расширение IBM для потоковых дампов с расширенной информацией. Точный формат javacore будет зависеть от версии JAVA, но будет включать в себя информацию об окружающей среде, информацию о памяти, информацию о потоках java и информацию о собственном стеке. Javacores будет иметь имя (по умолчанию) javacore.yyyymmdd.hhmmss. <Pid> .0001.txt и будет находиться в домашнем каталоге процесса JAVA. 0001 является порядковым номером и будет увеличиваться для каждого javacore для того же pid. В соответствии с расширенной информацией, предоставленной javacores, этот пример представляет собой фрагмент из javacore для полного профиля WebSphere Application Server, на котором выполняется более сложное приложение. Фрагмент javacore показан с текстовыми строками, которые помечают определенные разделы javacore, чтобы облегчить объяснение, и просто включает активную нить:

3XMTHREADINFO "Веб-контейнер: 10" J9VMThread: 0x3C7A7E00, j9thread_t: 0x357FF2DC, java / lang / Thread: 0x936873F0, состояние: B, prio = 5

3XMJAVALTHREAD (java / lang / Thread getId: 0xC5, isDaemon: true)

3XMTHREADINFO1 (собственный идентификатор потока: 0x18C00FD, собственный приоритет: 0x5, собственная политика: НЕИЗВЕСТНО)

3XMTHREADINFO3 Java callstack:

4XESTACKTRACE в com / sproket / workflow / service / dao / process / WorkflowSessionManager.getSession (WorkflowSessionManager.java:121 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / service / dao / process / WorkflowSessionManager.getSessionMap (WorkflowSessionManager.java:81 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / service / фасад / WorkflowServiceFacade.authenticateUser (WorkflowServiceFacade.java:167 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / service / ejb / WorkflowServiceBean.authenticateUser (WorkflowServiceBean.java:154 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / service / ejb / EJSRemoteStatelessWFServiceBean_c7a2c966.authenticateUser (байт-код ПК: 67 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / service / ejb / _WorkflowService_Stub.authenticateUser (_WorkflowService_Stub.java:335 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / service / access / WorkflowServiceAccess.authenticateUser (WorkflowServiceAccess.java:130 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / toolkit / controller / WorkflowAction.getWorkflowService (WorkflowAction.java:843 (скомпилированный код))

4XESTACKTRACE в com / sproket / workmanager / workflow / controller / QueueBrowseListPrepareAction.doPerform (QueueBrowseListPrepareAction.java:51 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / toolkit / controller / WorkflowAction.execute (WorkflowAction.java:331 (скомпилированный код))

4XESTACKTRACE в org / apache / struts / chain / commands / servlet / ExecuteAction.execute (ExecuteAction.java:58 (скомпилированный код))

4XESTACKTRACE в org / apache / struts / chain / commands / AbstractExecuteAction.execute (AbstractExecuteAction.java:67 (скомпилированный код))

4XESTACKTRACE в org / apache / struts / chain / commands / ActionCommandBase.execute (ActionCommandBase.java:51 (скомпилированный код))

4XESTACKTRACE в org / apache / commons / chain / impl / ChainBase.execute (ChainBase.java:191 (скомпилированный код))

4XESTACKTRACE в org / apache / commons / chain / generic / LookupCommand.execute (LookupCommand.java:305 (скомпилированный код))

4XESTACKTRACE в org / apache / commons / chain / impl / ChainBase.execute (ChainBase.java:191 (скомпилированный код))

4XESTACKTRACE в org / apache / struts / chain / ComposableRequestProcessor.process (ComposableRequestProcessor.java:283 (скомпилированный код))

4XESTACKTRACE в org / apache / struts / action / ActionServlet.process (ActionServlet.java:1913 (скомпилированный код))

4XESTACKTRACE в org / apache / struts / action / ActionServlet.doGet (ActionServlet.java:449 (скомпилированный код))

4XESTACKTRACE в javax / servlet / http / HttpServlet.service (HttpServlet.java:718 (скомпилированный код))

4XESTACKTRACE в javax / servlet / http / HttpServlet.service (HttpServlet.java:831 (скомпилированный код))

4XESTACKTRACE в com / ibm / ws / webcontainer / servlet / ServletWrapper.service (ServletWrapper.java:1661 (скомпилированный код))

4XESTACKTRACE в com / ibm / ws / webcontainer / servlet / ServletWrapper.service (ServletWrapper.java:1602 (скомпилированный код))

4XESTACKTRACE в com / ibm / ws / webcontainer / filter / WebAppFilterChain.doFilter (WebAppFilterChain.java:149 (скомпилированный код))

4XESTACKTRACE в com / sproket / workflow / toolkit / util / CharacterConverterFilter.doFilter (CharacterConverterFilter.java:32 (скомпилированный код))

4XESTACKTRACE в com / ibm / ws / webcontainer / filter / FilterInstanceWrapper.doFilter (FilterInstanceWrapper.java:190 (скомпилированный код))

4XESTACKTRACE в com / ibm / ws / webcontainer / filter / WebAppFilterChain.doFilter (WebAppFilterChain.java:125 (скомпилированный код))

Секретным соусом, который будет сопоставлять идентификаторы потока JAVA с отчетом инструмента производительности, является собственный идентификатор потока, который в примере javacore равен 0x18c00fd или tid = 0x00007fed40021000 в дампе потока. (Цвет текста добавлен для блога, чтобы помочь идентифицировать конкретную информацию).

Обычно в javacore или threaddump будут сотни потоков для умеренно сложного приложения. Вам нужно будет отфильтровать 3XMTHREADINFO1, чтобы найти каждый поток Java (из строк 3XMTHREADINFO), чтобы найти все потоки в javacores. Вы можете отфильтровать по tid =, чтобы найти их в threaddumps.

Чтобы применить секретный соус, идентификатор потока, сообщаемый инструментом повышения производительности, и собственные идентификаторы потока из javacore или threaddump, взятые в то же время, когда зарегистрированный отчет о производительности, должны быть преобразованы в общий формат, и тогда вы получите корреляцию. 0X18c00fd - это десятичное 259252509, и десятичное число чаще всего будет использоваться в отчетах о производительности на уровне системы.

Ваш опыт может отличаться, но желательно отсортировать потоки в отчете о производительности системы по использованию процессора и найти основных участников. Обычно это приводит к минимизации количества исследуемых потоков. Чаще всего, если существует более 20 потоков, все из которых потребляют незначительное количество процессора, проблема заключается в том, что на самом деле больше пользователей сочли приложение полезным или произошли некоторые недавние изменения, повлиявшие на использование процессора приложением. Теперь наилучший сценарий состоит в том, чтобы в отчетах о производительности только несколько потоков постоянно потребляли высокую производительность. Идеал - иметь его, но это не часто. Если у вас есть эти потоки, вы увидите «стеки» в информации о threaddump / javacore. Стеки - это вызовы, сделанные потоком, и они начинаются с последнего вызова метода и работают с обратными словами к первому. Вызовы методов помечаются 4XESTACKTRACE в javacores и могут иметь другие встроенные флаги. Чаще всего верхний метод в стеке - это какой-то служебный метод Java или метод инфраструктуры, который вызывается методом приложения, понятным для разработчиков. Во многих случаях будет много потоков в подобных стеках. Так что пример стека потоковой передачи из профиля Liberty не удивительно, что внутренняя обработка IBM выполняется при чтении nio. С другой стороны, в примере javacore выполняется вызов метода dao, который является частью приложения, и если он постоянно потребляет большое количество ресурсов процессора - пора привлекать разработчиков, и расследование начинается с фактической идентификации подозреваемых.

Два важных момента:

1) Вы всегда должны сопоставлять идентификаторы javacore / threaddump из отметки времени как можно ближе к отметке времени в журнале использования процессора. Серверы корпоративных приложений JAVA будут иметь расширения для основных возможностей потоков ОС, и поток JAVA может использовать один и тот же собственный поток в течение всего срока службы приложения, или он может быть уничтожен и воссоздан как отдельный собственный поток для каждого javacore / threaddump.

2) Если вы проводите это расследование очень часто и действительно успешно выполняете javacores в то же время, когда вы собираете статистику производительности, вы увидите, что Anonymous Native Thread потребляет процессор с некоторой регулярностью. Нет стека Java, но собственный стек (помеченный 4XENATIVESTACK) показывает:

3XMTHREADINFO Анонимная нить
3XMTHREADINFO1 (собственный идентификатор потока: 0xB22, собственный приоритет: 0x0, собственная политика: НЕИЗВЕСТНО)
3XMTHREADINFO3 Собственный стек вызовов:
4XENATIVESTACK (0x00002B529CEF90A2 [libj9prt24.so + 0xf0a2])
4XENATIVESTACK (0x00002B529CF03831 [libj9prt24.so + 0x19831])
4XENATIVESTACK (0x00002B529CEF912D [libj9prt24.so + 0xf12d])
4XENATIVESTACK (0x00002B529CEF923A [libj9prt24.so + 0xf23a])
4XENATIVESTACK (0x00002B529CEF8EE4 [libj9prt24.so + 0xeee4])
4XENATIVESTACK (0x00002B529CF03831 [libj9prt24.so + 0x19831])
4XENATIVESTACK (0x00002B529CEF8F5D [libj9prt24.so + 0xef5d])
4XENATIVESTACK (0x00002B529CEF4FA8 [libj9prt24.so + 0xafa8])
4XENATIVESTACK (0x00002B529CEF530F [libj9prt24.so + 0xb30f])
4XENATIVESTACK (0x00002B529CEF53CB [libj9prt24.so + 0xb3cb])
4XENATIVESTACK (0x00002B52A0A1A041 [libj9dmp24.so + 0x13041])
4XENATIVESTACK (0x00002B529CF03831 [libj9prt24.so + 0x19831])
4XENATIVESTACK (0x00002B52A0A166A0 [libj9dmp24.so + 0xf6a0])
4XENATIVESTACK (0x00002B52A0A19F5A [libj9dmp24.so + 0x12f5a])
4XENATIVESTACK (0x00002B529CF03831 [libj9prt24.so + 0x19831])
4XENATIVESTACK (0x00002B52A0A149A9 [libj9dmp24.so + 0xd9a9])
4XENATIVESTACK (0x00002B52A0A1A1DA [libj9dmp24.so + 0x131da])
4XENATIVESTACK (0x00002B52A0A0BA83 [libj9dmp24.so + 0x4a83])
4XENATIVESTACK (0x00002B52A0A0E9B5 [libj9dmp24.so + 0x79b5])
4XENATIVESTACK (0x00002B529CF03831 [libj9prt24.so + 0x19831])
4XENATIVESTACK (0x00002B52A0A0E98E [libj9dmp24.so + 0x798e])
4XENATIVESTACK (0x00002B52A0A0E5C9 [libj9dmp24.so + 0x75c9])
4XENATIVESTACK (0x00002B52A0A1B52A [libj9dmp24.so + 0x1452a])
4XENATIVESTACK (0x00002B52A1BE529D [libjclscar_24.so + 0x4d29d])
4XENATIVESTACK (0x00002B529CF03831 [libj9prt24.so + 0x19831])

Вы смотрите на поток, который записывает javacore в IBM JRE, и вы не должны рассматривать его как вероятный проблемный поток.

Примечание о IBM JAVA:

Начиная с IBM JAVA 7 SR 6, JAVA 626 SR7 и JAVA 7.1. Javacores включают накопительную информацию о процессорах для каждого потока в строке, помеченной как 3XMCPUTIME. Смотрите следующее:

3XMCPUTIME Общее использование ЦП: 0,249601600 с, пользователь: 0,218401400 с, система: 0,031200200 с.

Накопительный означает, что запись предназначена для жизни потока. В зависимости от конфигурации пулов потоков JVM и рассматриваемого потока, использование процессора может быть в течение срока службы приложения, в течение длительного периода или в течение нескольких циклов процессора. Рекомендуемой практикой является идентификация собственного идентификатора потока в нескольких javacores и проверка соответствия идентификатора потока java. Тогда загрузка процессора будет рассчитываться как разница в использовании процессора в javacores. Поскольку в каждом javacore может быть несколько тысяч потоков, инструмент поможет этому процессу.

Заключение:

Идентификация потоков JAVA с использованием процессора была объяснена.

Само расследование было применено ко многим тысячам проблем с производительностью. Он также может быть полезен для сбора базовых показателей производительности для дальнейшего использования или для планирования мощности.

Некоторая полезная информация:

Если вы хотите собрать некоторые рабочие сценарии, которые собирают необходимую информацию и советы по инструментам, которые используются в этой обработке расследования, перейдите по этой ссылке: http://www.ibm.com/support/search.wss?rs=180&tc=SSCMPB9+SSCMP9J&q=MustGatherDocument

Ссылка приведет вас к документам MustGather, которые содержат сценарии и инструменты, используемые службой поддержки IBM для сбора информации и исследования высокой производительности процессора.

Очень полезная альтернатива в WebSphere Application Server - использовать инструмент isadc и следовать инструкциям для сбора информации. После этого у вас будут отчеты и, в случае необходимости, и, если вам потребуется отправить информацию в службу поддержки IBM, вы можете сделать это с помощью записи проблем (PMR) или запроса на обслуживание (SR).

Вы также можете найти эти технические замечания по конкретному применению этой техники полезными:

название изображения (изменено) кредит: (cc) Некоторые права защищены от ClkerFreeVectorImages

Похожие