我們的客戶之一有一個新問題:應用程序停頓。線程轉儲顯示所有線程掛在JDBC調用中的網絡IO上。JDBC連接掛起
我們從未見過這些'網絡IO'掛起。通常情況下,帶有數據庫問題的慢機器具有a)一個或兩個長時間運行的查詢或b)某種類型的鎖定/死鎖。在這兩種情況下,線程都會掛在不同的方法上。我從來沒有看到網絡IO上掛着所有30多個線程。
下面我已經包含了線程轉儲的摘錄。所有HTTP線程掛在同一個java.net.SocketInputStream.read
呼叫。
我跟他們的dba和sysadmin聊過。根據他們最近在環境中「沒有任何變化」會導致這個問題。
分貝的環境
MSSQL 2005 64位Service Pack 2的 驅動程序:sqljdbc.jar:1.0 809 102
注:它們運行的是較舊的JDBC驅動程序。 AFAIK他們試圖從1.0升級到1.2的驅動程序,但還有其他一些問題。
他們正在同時運行的應用程序服務器和VMware虛擬機的數據庫服務器
其他環境問題。我不知道這個設置如何影響網絡性能。
顯然這是這個問題的唯一應用。我不知道他們的網絡架構。
問題 *有關此問題的任何見解? *如果是網絡,下一步是否需要分析?
附錄A:從線程轉儲摘錄
所有的HTTP連接都掛在同一個方法:
"TP-Processor31" daemon prio=5 tid=0x04085b78 nid=0x970 runnable [0x0764d000..0x0764fd6c] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at com.microsoft.sqlserver.jdbc.DBComms.receive(Unknown Source) at com.microsoft.sqlserver.jdbc.IOBuffer.sendCommand(Unknown Source) - locked (a com.microsoft.sqlserver.jdbc.DBComms) at com.microsoft.sqlserver.jdbc.SQLServerStatement.sendExecute(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteQuery(Unknown Source)
如果連接通過一個愚蠢的NAT網關 – nos 2009-08-07 21:26:40