WebSphere Application Hang

Если приложение WebSphere зависло в z/OS, какие шаги необходимо предпринять, чтобы найти причину?

До сих пор я брал дамп кучи, ядро ​​Java и дамп системы.

Ни один из потоков не заблокирован, нет проблем с памятью, и кажется, что потоков не существует. (Всего ~50, что вполне нормально.)

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

Что может быть причиной этого? Я рассматриваю событие с высокой загрузкой процессора, но не уверен, как это проверить задним числом.

Я получаю сообщение об ошибке, подобное этому 30 раз. 

BBOO0221W: WSVR0605W: Thread "WebSphere WLM Dispatch Thread t=008b74f8" (00000075) has been active for 720962 milliseconds and may be hung.  There is/are 30 thread(s) in total in the server that may be hung.
at sun.reflect.GeneratedMethodAccessor617.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at com.sun.faces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:126)
    at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:72)
    at javax.faces.component.UICommand.broadcast(UICommand.java:312)
    at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:267)
    at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:381)
    at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:75)
    at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
    at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97)
    at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:97)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
(truncated)

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

Источник

2 ответа

Решение

Одна из лучших функций z/OS - это возможности диагностики - вам никогда не придется угадывать... почти всегда можно точно узнать, что происходит.

Лично я бы начал с вашего системного дампа и IPCS. Конечно, в наши дни это довольно редкий навык, поэтому, если это не ваша вещь, первым шагом может стать поиск человека с хорошими навыками чтения дампов. Если вы полностью застряли, здесь есть хорошее введение.

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

Вы получите хороший обзор того, что происходит внутри WebSphere, используя форматтер дампа WebSphere IPCS - обзор здесь.

В адресном пространстве (ах) WebSphere будет много потоков, и они будут иметь TCB z/OS (блоки управления задачами). Просмотрите каждый последний TCB (в IPCS, команде SUMM FORMAT или эквивалентной) и выясните, выполняется ли она (возможно, зацикливается) или ожидает. Могу поспорить, что потоки ожидают того или иного... блокировки, внешнего сигнала, вызова DB2, какого-либо программного обеспечения вендора и т. Д. - хорошая цель - составить список всех потоков и того, что каждый один ждет.

В основном, поиск причины ожидания заключается в прохождении структур TCB/RB, чтобы найти PSW и регистры во время ожидания... это говорит вам о модуле, который ожидает, и, скорее всего, вы сможете выяснить, что происходит отсюда,

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

Кроме того, поскольку WebSphere является гигантским приложением UNIX Services, не забудьте взглянуть на OMVSDATA, если он у вас есть в дампе.

Не забывайте, что вы всегда можете обратиться за поддержкой в ​​IBM - вы тратите кучу денег на программное обеспечение, такое как WebSphere, поэтому попытка объяснить, что происходит, безусловно, является одной из лучших идей.

Удачи!

Источник

Приложение не отвечает, потому что все ваши потоки отправки (очевидно, 30) связаны. Новые запросы просто накапливаются в очереди WLM, пока не истечет некоторое время ожидания. Тайм-аут отправки в WAS z/OS должен в конечном итоге завершить область слуги, и WLM запустит новую (если вы не отключили тайм-аут). Хорошая статья об управлении таймаутом для WAS в z / OS здесь: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102510.

К сожалению, это все еще не объясняет, почему он застрял в первую очередь.

Источник
Другие вопросы по тегам