調試JBoss 100％CPU使用率

Question

最初發布on Server Fault，在那裏有人建議這個問題可能會在這裏更好地問。

我們使用JBoss來運行我們的兩個WAR。一個是我們的網絡應用程序，另一個是我們的網絡服務。 Web應用程序訪問另一臺計算機上的數據庫並向Web服務發出請求。 Web服務向其他機器發出JMS請求，彙總數據並將其返回。

在我們最大的客戶端，大約每月一次的JBoss Java進程佔所有CPU的100％。運行JBoss的機器有8個CPU。我們的網絡應用程序在這段時間內仍然可以訪問，但頁面大約需要3分鐘才能加載。重新啓動JBoss將一切恢復正常。

數據庫機器和所有其他機器都很好，只有運行JBoss的機器受到影響。內存使用情況正常。網絡利用率是正常的。 JBoss日誌中沒有可疑的錯誤消息。

我已經建立了一個儘可能接近客戶端生產環境的測試環境，並且我已經完成了負載測試，其併發用戶數量是2倍。我還沒有得到我的測試環境來重現問題。

我們從哪裏出發？我們如何縮小問題的範圍？

目前我們唯一的計劃是等到問題發生在自己的生產中，然後進行一些調試以確定原因。到目前爲止，人們在發生問題時剛剛重新啓動了JBoss以最大限度地縮短停機時間。下次發生時，他們會讓開發人員看一看。問題是，下次發生時，可以做什麼來確定原因？

我們可以在同一個盒子上設置一個單獨的JBoss實例，並從Web服務中單獨安裝Web應用程序。這樣，當下一個問題發生時，我們將知道哪個WAR有問題（假設它是我們的代碼）。儘管如此，這並沒有縮小範圍。

我應該啓用JMX remote嗎？通過這種方式，下次發生問題時，我可以使用VisualVM進行連接，查看哪些線程在使用CPU，以及他們在做什麼。但是，在生產環境中啓用JMX遠程控制是否有重大缺陷？

是否有另一種方法來查看哪些線程正在吃CPU，並得到一個堆棧跟蹤，看看他們在做什麼？

還有其他想法嗎？

謝謝！

Answer 1

我認爲你應該嘗試設置一個測試環境，進行一些負載測試以重現你的問題。性能分析絕對有助於查明問題。

一個快速修復將是下一次殺死與殺-3的jboss爲了得到轉儲分析。我要檢查的第二件事是，你使用-server標誌運行，並且你的gc設置是合理的。您也可以運行一些dstat來查看鎖定過程中的過程。但是，再次 - 建立一個負載測試環境（通過EC2左右）來重現這一點可能更安全。

Answer 2

這通常發生在失控代碼或不安全的線程訪問hashmaps。一個簡單的線程轉儲（殺死-3，就像@disown說的，或者在Windows控制檯中按ctrl-break）將會揭示這個問題。

由於你無法使用測試重現它，我認爲它聞起來像一個併發問題;通常很難讓測試腳本表現出足夠的隨機性來捕捉這種類型的問題。

我通常會嘗試使其執行標準操作過程，以執行線程轉儲任何由於操作異常而重新啓動的JVM，並且確實需要捕獲那些每月一次的事情。

Answer 3

有一種快速和骯髒的方式來確定哪些線程正在使用JBoss上的CPU時間。使用瀏覽器訪問JMX控制檯（通常在http://localhost:8080/jmx-console，但可能會有所不同），尋找名爲ServerInfo的bean，它有一個名爲listThreadCpuUtilization的操作，它將每個活動線程使用的實際CPU時間轉儲爲一個很好的表格格式。如果有一個行爲不端，它通常會像拇指一樣突出。

還有listThreadDump操作將每個線程的堆棧轉儲到瀏覽器。

不如分析器，但獲得基本信息更簡單的方法。對於生產服務器來說，連接分析器通常是個壞消息，這非常方便。

Answer 4

如果您使用的是JBoss 5.1.0 EAP，那麼Jboss中存在一個錯誤，它們也有修復。 這裏是網址： https://issues.jboss.org/browse/JBPAPP-5193