Glassfish線程池問題

Question

我們使用的是Glassfish 3.0.1，並且遇到很長的響應時間;對於我們的POST/PUT請求的25％，在響應返回時前端負載均衡器超時的時間爲5分鐘。

我的理論是請求排隊等待可用線程。

我認爲這是因爲訪問日誌顯示請求需要幾秒鐘才能完成，但請求正在執行的時間比我預期的要晚五分鐘。

有沒有人有任何建議調試線程池發生了什麼？或者最適合他們的設置是什麼？

是否需要定期執行線程轉儲或者一次性轉儲是否足夠？

Answer 1

乍一看，這似乎與線程本身很少有關。在不瞭解網絡設置的其餘部分的情況下，我會檢查以下內容：

• 負載平衡器池中是否存在死/無響應節點？這可能導致所有請求都被嘗試對該節點進行嘗試，直到它們在重定向到其他節點之前由於超時而失敗。
• 負載均衡器和Glassfish服務器之間的初始連接是否存在一些問題？這可能是緩慢或不正確的DNS查找（儘管服務器應緩存結果），缺少代理或其他與網絡有關的問題。
• 您是否檢查過機器之間的時鐘是否同步？這可能會導致日誌不同步。 5分鐘是一個非常奇怪的超時時間。

如果所有這些都空了，您可能只是負載平衡器和Web服務器之間的阻抗不匹配，您可能需要添加Web服務器來處理負載。負載均衡器應該能夠爲您提供大量的流量統計數據以及它的堆疊情況。

Answer 2

考慮threaddump是調試線程池正在進行的最佳方法。請在每個線程轉儲之間以1-2秒的間隔依次進行3-4次線程轉儲。

在threaddump中，可以通過名稱找到工作線程的數量。從多個線程轉儲中找出長時間運行的線程。

您可以使用TDA工具（http://java.net/projects/tda/downloads/download/tda-bin-2.2.zip）分析線程轉儲。

Answer 3

如果您在服務器中配置的工作線程不足，通常會​​出現此問題。普通網絡服務器中的默認值範圍爲15到100個線程。但是，如果您的應用程序阻塞了服務器的工作線程（例如通過等待查詢），則默認值的頻率太低。 您可以將工作人員的數量增加到1000個（確保64位）。還要檢查任何中間服務器（例如代理或通過mod_proxy的apache轉發）的workerthread數（有時稱爲「最大併發/打開請求數」）。

另一個常見的錯誤是軟件向自己發送請求（例如嘗試重新路由或轉發請求），同時阻止傳入的請求。