目錄

1.網絡

1.1 檢查nginx的網絡情況

1.2 檢查tomcat的網絡情況

2.Jvm內存溢出

2.1為什么會發生內存泄漏

2.2快速定位問題

2.3 jstack查看tomcat是否出現死鎖

2.4 jstat查看gc運行情況

?2.5 jmap獲取內存快照

3. jvm GC 時間過長,導致應用暫停

4. load 太高,已經超出服務的極限

5. 大量tcp 連接 TIME_WAIT

6. tomcat長連接數超過最大連接數

1.網絡

1.1 檢查nginx的網絡情況

? ? 更改nginx的配置，讓該臺nginx請求只轉到本機器的出現問題的tomcat應用上面，在access.log里看是否有網絡請求，結果可以查看到當前所有的網絡請求，也就是說可以排除是網絡的問題。

1.2 檢查tomcat的網絡情況

? ? 分析業務配置的tomcat訪問日志xxxx.log上是否有日志訪問記錄，經過查詢該臺tomcat應用日志完全沒有任何訪問記錄，由于我們的部署是本機的nginx轉到本機的tomcat應用，所以可以排除不是網絡問題。 到此基本可以斷定網絡沒有問題，tomcat 本身出現了假死的情況。在tomcat的日志里有報過OutOfMemoryError的異常，所以可以肯定tomcat假死的原因是OOM
！

2.Jvm內存溢出

2.1為什么會發生內存泄漏

? ? 在我們學習Java的時候就知道它最為方便的地方就是我們不需要管理內存的分配和釋放，一切由JVM自己來進行處理，當Java對象不再被應用時，等到堆內存不夠用時JVM會進行GC處理， 清除這些對象占用的堆內存空間，但是如果對象一直被應用，那么JVM是無法對其進行GC處理的，那么我們創建新的對象時，JVM就沒有辦法從堆中獲取足夠的內存分配給此對象，這時就會導致OOM。 我們出現OOM原因，一般都是因為我們不斷的往容器里存放對象，然而容器沒有相應的大小限制或清除機制，這樣就容易導致OOM。

2.2快速定位問題

當我們的應用服務器占用了過多內存的時候，我們怎么樣才能快速的定位問題呢？要想快速定位問題，首先我們必需獲取服務器JVM某時刻的內存快照。 Jdk里面提供了很多相應的命令比如：jstack,jstat,jmap,jps等等. 在出現問題后我們應該快速保留現場。

2.3 jstack查看tomcat是否出現死鎖

? ? 可以觀察到jvm中當前所有線程的運行情況和線程當前狀態.

sudo jstack -F 進程ID

輸出內容如下： 從上面的圖我們可以看到tomcat進程里面沒有死鎖的情況，而且每個線程都處理等待的狀態。這個時候我們可以telnet命令連上tomcat的端口查看tomcat進程是否有任務回應。這時發現tomcat沒有任何回應可以證明tomcat應用已沒有響應處理假死狀態。

在thread dump中，要留意下面幾種狀態 死鎖， ? Deadlock（重點關注） 等待資源， ? Waiting on condition（重點關注） ? 等待獲取監視器，Waiting on monitor entry（重點關注） ? 阻塞，Blocked（重點關注） ? 執行中，Runnable ? 暫停，Suspended ? 對象等待中，Object.wait() 或 TIMED_WAITING ? 停止，Parked

2.4 jstat查看gc運行情況

?2.5 jmap獲取內存快照

Jdk自帶的jmap可以獲取內在某一時刻的快照

命令：

jmap -dump:format=b,file=heap.bin?file：保存路徑及文件名 pid：進程編號（windows通過任務管理器查看，linux通過ps aux查看）

dump文件可以通過MemoryAnalyzer分析查看，網址：http://www.eclipse.org/mat/，可以查看dump時對象數量，內存占用，線程情況等。
?

3. jvm GC 時間過長,導致應用暫停

查看gc.log回收時間，以下為例子：

7581088.402: [Full GC (System) 7581088.402: [CMS: 661091K->669762K(7340032K), 1.7206330 secs] 848607K->669762K(8238848K), [CMS Perm : 34999K->34976K(58372K)], 1.7209480 secs] [Times: user=1.72 sys=0.00, real=1.72 secs]

最近的一次full gc 顯示,也不應該會暫停幾分鐘的情況,這種假死可能可以排除。

4. load 太高,已經超出服務的極限

使用top 命令查看資源使用情況，都在合理范圍，排除。

5. 大量tcp 連接 TIME_WAIT

Linux:

使用 ss -s 命令查看 tcp 鏈接狀態， 發現TIME_WAIT 1800+, 有點高，需要修改。

打開 sysctl.conf 文件，修改以下幾個參數：

[root@web01 ~]# vim /etc/sysctl.confnet.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_timestamps = 1net.ipv4.tcp_syncookies = 1net.ipv4.tcp_fin_timeout = 30

開啟tcp_tw_reuse 和 tcp_tw_recycle 需要timestamps的支持，而且這些配置一般不建議開啟，但是對解決TIME_WAIT過多問題有效果。謹慎操作！！！

然后又發現，nginx 沒有開啟長連接。

當使用nginx作為反向代理時，為了支持長連接，需要做到兩點：

• 從client到nginx的連接是長連接
• 從nginx到server的連接是長連接

Windows:

netstat -ano -p tcpnetstat -ano | find "ESTABLISHED"

5.1、保持和client的長連接：

http {keepalive_timeout 120s 120s;keepalive_requests 10000; }

1）keepalive_timeout
語法:

keepalive_timeout timeout [header_timeout];

第一個參數：設置keep-alive客戶端連接在服務器端保持開啟的超時值（默認75s）；值為0會禁用keep-alive客戶端連接；

第二個參數：可選、在響應的header域中設置一個值“Keep-Alive: timeout=time”；通常可以不用設置；

注：keepalive_timeout默認75s，一般情況下也夠用，對于一些請求比較大的內部服務器通訊的場景，適當加大為120s或者300s；

2）keepalive_requests：

keepalive_requests指令用于設置一個keep-alive連接上可以服務的請求的最大數量，當最大請求數量達到時，連接被關閉。默認是100。這個參數的真實含義，是指一個keep alive建立之后，nginx就會為這個連接設置一個計數器，記錄這個keep alive的長連接上已經接收并處理的客戶端請求的數量。如果達到這個參數設置的最大值時，則nginx會強行關閉這個長連接，逼迫客戶端不得不重新建立新的長連接。

大多數情況下當QPS(每秒請求數)不是很高時，默認值100湊合夠用。但是，對于一些QPS比較高（比如超過10000QPS，甚至達到30000,50000甚至更高) 的場景，默認的100就顯得太低。

簡單計算一下，QPS=10000時，客戶端每秒發送10000個請求(通常建立有多個長連接)，每個連接只能最多跑100次請求，意味著平均每秒鐘就會有100個長連接因此被nginx關閉。同樣意味著為了保持QPS，客戶端不得不每秒中重新新建100個連接。因此，就會發現有大量的TIME_WAIT的socket連接(即使此時keep alive已經在client和nginx之間生效)。因此對于QPS較高的場景，非常有必要加大這個參數，以避免出現大量連接被生成再拋棄的情況，減少TIME_WAIT。

5.2、保持和server的長連接：

nginx訪問后端默認都是用的短連接(HTTP1.0）

為了讓nginx和后端server（nginx稱為upstream）之間保持長連接，location中有兩個參數需要設置：

http {server {location / {proxy_http_version 1.1;proxy_set_header Connection "";}} }

5.3、 proxy_set_header 配置注意事項

在當前級別的配置中沒有定義 proxy_set_header 指令時，這些指令從上級繼承。
如果當前級別的配置中已經定義了 proxy_set_header 指令，在上級中定義的proxy_set_header 指令在當前級別都會失效。

舉個例子：

http {...proxy_http_version 1.1;proxy_set_header Host $host;proxy_set_header Connection "";proxy_set_header X-Real-IP $remote_addr;upstream example.com_test {server 127.0.0.1:8080;keepalive 16;}server {server_name example.com;location ^~ /test/ {proxy_set_header test test;proxy_pass http://example.com_test;}} }

這里后端服務器不能從 Header 中獲取到 X-Real-IP。location ^~/test/ 中的proxy_set_header會覆蓋上面的配置。

正確的做法，在location 中重復配置一遍：

http {...proxy_http_version 1.1;proxy_set_header Host $host;proxy_set_header Connection "";proxy_set_header X-Real-IP $remote_addr;upstream example.com_test {server 127.0.0.1:8080;keepalive 180;}server {server_name example.com;location ^~ /test/ {proxy_set_header test test;proxy_set_header Host $host;proxy_set_header Connection "";proxy_set_header X-Real-IP $remote_addr;proxy_pass http://example.com_test;}} }

6. tomcat長連接數超過最大連接數

發現tomcat 使用的是默認配置

tomcat默認最大連接數(線程數)200個,默認每一個連接的生命周期2小時(7200秒),tomcat使用http 1.1協議，而http1.1默認是長連接。tomcat接受處理完請求后，socket沒有主動關閉，因此如果在2小時內，請求數超過200個，服務器就會出現上述假死現象。

解決辦法：

（1）檢查代碼，及時斷開socket

（2）修改tomcat配置文件，修改最大連接數(增大)

?（3）修改linux的TCP超時時間(socket生命周期)限制

?

總結

以上是生活随笔為你收集整理的Tomcat进程假死问题排查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。