oracle線程阻塞

本案例研究描述了在AIX 6.1和IBM Java VM 1.6上運(yùn)行的Oracle Service Bus 11g遇到的線程阻塞問題的完整根本原因分析過程。 本文也是您提高線程轉(zhuǎn)儲(chǔ)分析技能的絕佳機(jī)會(huì)，我強(qiáng)烈建議您學(xué)習(xí)并正確理解以下分析方法。 它還將展示正確數(shù)據(jù)收集的重要性，而不是過早的中間件（Weblogic）重新啟動(dòng)。

環(huán)境規(guī)格

• Java EE服務(wù)器：Oracle Service Bus 11g
• 操作系統(tǒng)：AIX 6.1
• JDK：IBM JRE 1.6.0 @ 64位
• RDBMS：Oracle 10g
• 平臺(tái)類型：企業(yè)服務(wù)總線

故障排除工具

• Quest Software Foglight for Java（監(jiān)視和警報(bào)）
• Java VM線程轉(zhuǎn)儲(chǔ)（IBM JRE javacore格式）

問題概述
?
從我們的Oracle Service Bus Weblogic環(huán)境中觀察到主要性能下降。 Foglight代理還發(fā)送了警報(bào)，表明Weblogic線程使用率顯著增加。

事實(shí)的收集和驗(yàn)證
?
通常，Java EE問題調(diào)查需要收集技術(shù)事實(shí)和非技術(shù)事實(shí)，因此我們可以得出其他事實(shí)和/或就根本原因進(jìn)行結(jié)論。 在采取糾正措施之前，要對(duì)以下事實(shí)進(jìn)行驗(yàn)證，以便得出根本原因：

• 對(duì)客戶有什么影響？ 高
• 受影響平臺(tái)的最近更改？ 是的，在中斷報(bào)告之前，OSB控制臺(tái)中的一些業(yè)務(wù)服務(wù)的日志記錄級(jí)別已更改
• 受影響平臺(tái)最近的流量增加了嗎？ 沒有
• 從多久以來觀察到此問題？ 日志記錄級(jí)別更改后觀察到新問題
• 重新啟動(dòng)Weblogic服務(wù)器是否可以解決問題？ 是

結(jié)論＃1 ：先前在某些OSB業(yè)務(wù)服務(wù)上應(yīng)用的日志記錄級(jí)別更改似乎觸發(fā)了此線程阻塞問題。 但是，此時(shí)的根本原因仍然未知。

Weblogic線程監(jiān)視：Foglight for Java
?
Foglight for Java （來自Quest Software）是一款出色的監(jiān)視工具，可讓您完全監(jiān)視任何Java EE環(huán)境以及完整的警報(bào)功能。 該工具在我們的生產(chǎn)環(huán)境中用于監(jiān)視每個(gè)Oracle Service Bus受管服務(wù)器的中間件（Weblogic）數(shù)據(jù)，包括線程。 您可以在下面看到線程的持續(xù)增加以及未決的請(qǐng)求隊(duì)列。

供您參考，Weblogic運(yùn)行緩慢的線程被標(biāo)識(shí)為“正在運(yùn)行的線程”，如果運(yùn)行幾分鐘（根據(jù)您配置的閾值），最終可以提升為“ STUCK”狀態(tài)。

現(xiàn)在，您下一步應(yīng)該采取什么行動(dòng)？ Weblogic重新啟動(dòng)？ 絕對(duì)不是……針對(duì)此類問題的第一個(gè)“React”是捕獲JVM線程轉(zhuǎn)儲(chǔ)。 此類數(shù)據(jù)對(duì)于您執(zhí)行正確的根本原因分析并了解潛在的懸掛狀況至關(guān)重要。 捕獲到此類數(shù)據(jù)后，您就可以繼續(xù)執(zhí)行Weblogic服務(wù)器恢復(fù)操作，例如重新啟動(dòng)完全托管服務(wù)器（JVM）。

線程卡住：線程轉(zhuǎn)儲(chǔ)可以救援！
?
此中斷場景中的下一個(gè)操作步驟是在嘗試恢復(fù)受影響的Weblogic實(shí)例之前，從IBM JVM快速生成一些線程轉(zhuǎn)儲(chǔ)快照。 使用kill -3 <Java PID>生成了線程轉(zhuǎn)儲(chǔ)，該腳本確實(shí)在Weblogic域的根目錄生成了一些javacore文件。

javacore.20120610.122028.15149052.0001.txt

一旦生產(chǎn)環(huán)境備份并開始運(yùn)行，團(tuán)隊(duì)將按照以下步驟Swift進(jìn)行捕獲的線程轉(zhuǎn)儲(chǔ)文件的分析。

線程轉(zhuǎn)儲(chǔ)分析步驟＃1 –確定線程執(zhí)行模式
?
第一步是快速遍歷所有Weblogic線程，并嘗試確定常見的問題模式，例如從遠(yuǎn)程外部系統(tǒng)等待的線程，處于死鎖狀態(tài)的線程，從其他線程等待以完成其任務(wù)的線程等。

分析確實(shí)Swift揭示出許多線程處于與以下相同的阻塞情況中。 在此示例中，我們可以在TransactionManager Java類（OSB內(nèi)核代碼）中看到處于阻塞狀態(tài)的Oracle Service Bus線程。

[ACTIVE] ExecuteThread: '292' for queue: 'weblogic.kernel.Default (self-tuning)'"J9VMThread:0x0000000139B76B00, j9thread_t:0x000000013971C9A0,java/lang/Thread:0x07000000F9D80630, state:B, prio=5(native thread ID:0x2C700D1, native priority:0x5, native policy:UNKNOWN)Java callstack:at com/bea/wli/config/transaction/TransactionManager._beginTransaction(TransactionManager.java:547(Compiled Code))at com/bea/wli/config/transaction/TransactionManager.beginTransaction(TransactionManager.java:409(Compiled Code))at com/bea/wli/config/derivedcache/DerivedResourceManager.getDerivedValueInfo(DerivedResourceManager.java:339(Compiled Code))at com/bea/wli/config/derivedcache/DerivedResourceManager.get(DerivedResourceManager.java:386(Compiled Code))at com/bea/wli/sb/resources/cache/DefaultDerivedTypeDef.getDerivedValue(DefaultDerivedTypeDef.java:106(Compiled Code))at com/bea/wli/sb/pipeline/RouterRuntimeCache.getRuntime(RouterRuntimeCache.java(Compiled Code))at com/bea/wli/sb/pipeline/RouterManager.getRouterRuntime(RouterManager.java:640(Compiled Code))at com/bea/wli/sb/pipeline/RouterContext.getInstance(RouterContext.java:172(Compiled Code))at com/bea/wli/sb/pipeline/RouterManager.processMessage(RouterManager.java:579(Compiled Code))at com/bea/wli/sb/transports/TransportManagerImpl.receiveMessage(TransportManagerImpl.java:375(Compiled Code))at com/bea/wli/sb/transports/local/LocalMessageContext$1.run(LocalMessageContext.java:179(Compiled Code))at weblogic/security/acl/internal/AuthenticatedSubject.doAs(AuthenticatedSubject.java:363(Compiled Code))at weblogic/security/service/SecurityManager.runAs(SecurityManager.java:146(Compiled Code))at weblogic/security/Security.runAs(Security.java:61(Compiled Code))at com/bea/wli/sb/transports/local/LocalMessageContext.send(LocalMessageContext.java:144(Compiled Code))at com/bea/wli/sb/transports/local/LocalTransportProvider.sendMessageAsync(LocalTransportProvider.java:322(Compiled Code))at sun/reflect/GeneratedMethodAccessor980.invoke(Bytecode PC:58(Compiled Code))at sun/reflect/DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37(Compiled Code))at java/lang/reflect/Method.invoke(Method.java:589(Compiled Code))at com/bea/wli/sb/transports/Util$1.invoke(Util.java:83(Compiled Code))at $Proxy111.sendMessageAsync(Bytecode PC:26(Compiled Code)) ……………………………

線程轉(zhuǎn)儲(chǔ)分析步驟2 –檢查被阻塞的線程鏈
?
下一步是檢查涉及我們確定的模式的受影響和受阻的線程鏈。 正如我們?cè)诰€程轉(zhuǎn)儲(chǔ)分析的第4部分中所看到的那樣，IBM JVM線程轉(zhuǎn)儲(chǔ)格式包含一個(gè)單獨(dú)的部分，該部分提供了所有線程阻塞鏈的完整細(xì)分，例如Java對(duì)象監(jiān)視器池鎖。

快速分析確實(shí)揭示了以下線程元兇。 如您所見，Weblogic線程16是實(shí)際的罪魁禍?zhǔn)?#xff0c;有300多個(gè)線程正在等待獲取共享對(duì)象監(jiān)視器TransactionManager @ 0x0700000001A51610 / 0x0700000001A51628上的鎖。

2LKMONINUSE sys_mon_t:0x000000012CCE2688 infl_mon_t: 0x000000012CCE26C8: 3LKMONOBJECT com/bea/wli/config/transaction/TransactionManager@0x0700000001A51610/0x0700000001A51628: Flat locked by "[ACTIVE] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000012CA3C800), entry count 1 3LKWAITERQ Waiting to enter: 3LKWAITER "[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000011C785C00) 3LKWAITER "[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000011CA93200) 3LKWAITER "[STUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000011B3F2B00) 3LKWAITER "[STUCK] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000011619B300) 3LKWAITER "[STUCK] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000012CBE8000) 3LKWAITER "[STUCK] ExecuteThread: '21' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000012BE91200) ..................

線程轉(zhuǎn)儲(chǔ)分析步驟＃3 –線程元兇更深入的分析
?
一旦確定了罪魁禍?zhǔn)?#xff0c;下一步就是對(duì)該線程當(dāng)前正在執(zhí)行的計(jì)算任務(wù)進(jìn)行更深入的審查。 只需返回原始線程轉(zhuǎn)儲(chǔ)數(shù)據(jù)，并從下至上開始分析罪魁禍?zhǔn)拙€程堆棧跟蹤。

正如您在下面看到的那樣，針對(duì)我們的問題案例的線程堆棧跟蹤非常清楚。 它確實(shí)表明線程＃16當(dāng)前正在嘗試提交在Weblogic / Oracle Service Bus級(jí)別進(jìn)行的更改。 問題在于，提交操作正在掛起并且花費(fèi)了太多時(shí)間，導(dǎo)致線程＃16保留來自TransactionManager的共享對(duì)象監(jiān)視器鎖定的時(shí)間太長，并使其他Oracle Service Bus Weblogic線程“饑餓”。

"[ACTIVE] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'" J9VMThread:0x000000012CA3C800, j9thread_t:0x000000012C9F0F40, java/lang/Thread:0x0700000026FCE120, state:P, prio=5 (native thread ID:0x35B0097, native priority:0x5, native policy:UNKNOWN)Java callstack:at sun/misc/Unsafe.park(Native Method)at java/util/concurrent/locks/LockSupport.park(LockSupport.java:184(Compiled Code))at java/util/concurrent/locks/AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:822)at java/util/concurrent/locks/AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:853(Compiled Code))at java/util/concurrent/locks/AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1189(Compiled Code))at java/util/concurrent/locks/ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:911(Compiled Code))at com/bea/wli/config/derivedcache/DerivedCache$Purger.changesCommitted(DerivedCache.java:80)at com/bea/wli/config/impl/ResourceListenerNotifier.afterEnd(ResourceListenerNotifier.java:120)at com/bea/wli/config/transaction/TransactionListenerWrapper.afterEnd(TransactionListenerWrapper.java:90)at com/bea/wli/config/transaction/TransactionManager.notifyAfterEnd(TransactionManager.java:1154(Compiled Code))at com/bea/wli/config/transaction/TransactionManager.commit(TransactionManager.java:1519(Compiled Code))at com/bea/wli/config/transaction/TransactionManager._endTransaction(TransactionManager.java:842(Compiled Code))at com/bea/wli/config/transaction/TransactionManager.endTransaction(TransactionManager.java:783(Compiled Code))at com/bea/wli/config/deployment/server/ServerDeploymentReceiver$2.run(ServerDeploymentReceiver.java:275)at weblogic/security/acl/internal/AuthenticatedSubject.doAs(AuthenticatedSubject.java:321(Compiled Code))at weblogic/security/service/SecurityManager.runAs(SecurityManager.java:120(Compiled Code))at com/bea/wli/config/deployment/server/ServerDeploymentReceiver.commit(ServerDeploymentReceiver.java:260)at weblogic/deploy/service/internal/targetserver/DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)at weblogic/deploy/service/internal/targetserver/DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)at weblogic/deploy/service/internal/targetserver/DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)at weblogic/work/SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528(Compiled Code))at weblogic/work/ExecuteThread.execute(ExecuteThread.java:203(Compiled Code))at weblogic/work/ExecuteThread.run(ExecuteThread.java:171(Compiled Code))

根本原因：連接點(diǎn)
?
在這一點(diǎn)上，事實(shí)和線程轉(zhuǎn)儲(chǔ)分析的收集確實(shí)使我們能夠確定事件鏈如下：

• 生產(chǎn)Oracle Service Bus管理員應(yīng)用的日志記錄級(jí)別更改
• Weblogic部署線程＃16無法正確提交更改
• 執(zhí)行客戶端請(qǐng)求的Weblogic運(yùn)行時(shí)線程Swift開始排隊(duì)，并等待共享庫監(jiān)視器（TransactionManager）上的鎖定
• Weblogic實(shí)例的線程不足，生成警報(bào)并迫使生產(chǎn)支持團(tuán)隊(duì)關(guān)閉并重新啟動(dòng)受影響的JVM進(jìn)程

我們的團(tuán)隊(duì)計(jì)劃不久后開放一個(gè)Oracle SR，以共享此OSB部署行為以及客戶端請(qǐng)求（線程）和OSB日志記錄層之間的硬依賴性。 在此期間，除非另行通知，否則不會(huì)在維護(hù)時(shí)段內(nèi)嘗試更改OSB日志記錄級(jí)別。

結(jié)論
?
我希望本文能幫助您了解和理解強(qiáng)大的線程轉(zhuǎn)儲(chǔ)分析功能，以查明阻塞線程問題的根本原因，以及任何Java EE生產(chǎn)支持團(tuán)隊(duì)捕獲此類重要數(shù)據(jù)以防止將來再次發(fā)生的重要性。 請(qǐng)不要猶豫，發(fā)表任何評(píng)論或問題。

參考： Oracle Service Bus –我們JCG合作伙伴 Pierre-Hugues Charbonneau的“ 阻塞線程”案例研究 ，位于Java EE支持模式和Java教程博客。

翻譯自: https://www.javacodegeeks.com/2012/08/oracle-service-bus-stuck-thread-case.html

oracle線程阻塞

總結(jié)

以上是生活随笔為你收集整理的oracle线程阻塞_Oracle Service Bus –线程阻塞案例研究的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。