Статьи

Обнаружение застрявших потоков в Oracle Weblogic

Июль 2, 2018

Следующий вопрос еще раз проверит ваши знания о поточной модели Oracle Weblogic. Я с нетерпением жду ваших комментариев и опыта на том же.

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


Застрявший поток в Weblogic просто означает поток, выполняющий один и тот же  запрос в течение очень длительного времени и больше, чем настраиваемое 
Максимальное время застрявшего потока 
.

Вопрос:

Как вы можете обнаружить присутствие потоков STUCK во время и после производственного инцидента?
Ответ:

Как мы видели из нашей последней статьи 
«Советы по мониторингу потоков Weblogic» , Weblogic предоставляет функциональные возможности, позволяющие нам тщательно контролировать его внутренний самонастраивающийся пул потоков. Это также подскажет вам наличие любой застрявшей нити.

Это представление мониторинга очень полезно, когда вы проводите анализ в реальном времени, но как быть 
после  производственного инцидента? Хорошая новость заключается в том, что Oracle Weblogic также регистрирует все обнаруженные застрявшие потоки в журнале сервера. Такая информация включает в себя детали запроса и, что более важно, трассировку стека потоков. Эти данные имеют решающее значение и позволят вам лучше понять основную причину любого состояния замедления, которое произошло в определенное время.
<Sep 25, 2013 7:23:02 AM EST> <Error> <WebLogicServer> <Server1> <App1>
< ExecuteThread: '11' for queue: 'weblogic.kernel.Default (self-tuning)'>
<BEA-000337> <[STUCK] ExecuteThread: '35' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "608" seconds working on the request
"Workmanager: default, Version: 0, Scheduled=true, Started=true, Started time: 608213 ms
POST /App1/jsp/test.jsp HTTP/1.1
Accept: application/x-ms-application...
Referer: http://..
Accept-Language: en-US
User-Agent: Mozilla/4.0 ..
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Content-Length: 539
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: JSESSIONID=
]", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
  <Application Execution Stack Trace>
  ...................................
  javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
  javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
  weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
  weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
  weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)
  weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:184)
  weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction....
  weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run()
  weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
  weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
  weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2281)
  weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2180)
  weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1491)
  weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
  weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

Вот еще один совет: создание и анализ дампа потоков JVM также выделит застрявшие потоки. Как видно из снимка ниже, состояние потока Weblogic теперь обновляется до STUCK, что означает, что этот конкретный запрос выполняется по крайней мере за 600 секунд или 10 минут. 


Это очень полезная информация, поскольку собственное состояние потока обычно остается в состоянии RUNNABLE. Состояние собственного потока будет обновляться только при работе с BLOCKED-потоками и т. Д. Вы должны иметь в виду, что RUNNABLE просто означает, что этот поток исправен с точки зрения JVM. Однако это не означает, что это действительно с точки зрения промежуточного программного обеспечения или контейнера Java EE. Вот почему Oracle Weblogic имеет свое собственное внутреннее состояние ExecuteThread.

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

43
Share: