Tomcat性能優化

最近一直在解決線上一個問題，表現是：

Tomcat每到凌晨會有一個高峯，峯值的併發達到了3000以上，最後的結果是Tomcat線程池滿了，日誌看不少請求超過了1s。

服務器性能很好，Tomcat版本是7.0.54，配置以下：

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
        maxThreads="3000" minSpareThreads="800"/>

    <Connector executor="tomcatThreadPool" port="8084" protocol="org.apache.coyote.http11.Http11AprProtocol"
               connectionTimeout="60000"
               keepAliveTimeout="30000"
               maxKeepAliveRequests="8000"
               maxHttpHeaderSize="8192"
               URIEncoding="UTF-8"
               enableLookups="false"
               acceptCount="1000"
               disableUploadTimeout="true"
               redirectPort="8443" />

過後thread dump看其實真正處於RUNNABLE狀態的線程不多，絕大部分線程都處於TIMED_WAITING狀態：

因而大夥都開始糾結爲何線程會漲到3000，並且發現即便峯值過了線程數並不會降下來。

咱們首先想到的是：

後端應用的處理瞬間比較慢，「堵住了」致使前端線程數漲了起來。

可是優化一個版本上線後發現雖然漲的狀況有所好轉，可是最終線程池仍是會達到3000這個最大值。

==================================分割線=========================================

以上是大背景，中間的過程省略，直接跟各位說下目前我獲得的結論：

一、首先是爲何線程不釋放的問題？

簡單說下我驗證的Tomcat(7.0.54)線程池大概的工做機制

• Tomcat啓動時若是沒有請求過來，那麼線程數（都是指線程池的）爲0；
• 一旦有請求，Tomcat會初始化minSapreThreads設置的線程數；
• Tomcat不會主動對線程池進行收縮，除非肯定沒有任何請求的時候，Tomcat纔會將線程池收縮到minSpareThreads設置的大小；
• Tomcat6以前的版本有一個maxSpareThreads參數，可是在7中已經移除了，因此只要前面哪怕只有一個請求，Tomcat也不會釋放多於空閒的線程。

至於Tomcat爲何移除maxSpareThreads這個參數，我想也是出於性能的考慮，不停的收縮線程池性能確定不高，而多餘的線程處於等待狀態的好處是一有新請求過來馬上能夠處理。

• 並且大量的Tomcat線程處於等待狀態不會消耗CPU，可是會消耗一些JVM存儲。

 

補充：上面標紅的一句有點問題，進一步驗證發現只有使用Keep-Alive（客戶端和服務端都支持）時纔是這種表現，若是客戶端沒有使用Keep-Alive那麼線程會隨着TCP鏈接的釋放而回收。

Tomcat中Keep-Alive相關的參數：

maxKeepAliveRequests:

The maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.

keepAliveTimeout:

The number of milliseconds this Connector will wait for another HTTP request before closing the connection. The default value is to use the value that has been set for the connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout. 

 

二、爲何線程池會滿？

這是我如今糾結的核心。究竟是不是應用的性能慢致使的，我如今的結論是有關係，但關鍵是併發。

• Tomcat的線程池的線程數跟你的瞬間併發有關係，好比maxThreads設置爲1000，當瞬間併發達到1000那麼Tomcat就會起1000個線程來處理，這時候跟你應用的快慢關係不大。

那麼是否是併發多少Tomcat就會起多少個線程呢？這裏還跟Tomcat的這幾個參數設置有關係，看官方的解釋是最靠譜的：

maxThreads:

The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool.

maxConnections:

The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will accept, but not process, one further connection. This additional connection be blocked until the number of connections being processed falls below maxConnections at which point the server will start accepting and processing new connections again. Note that once the limit has been reached, the operating system may still accept connections based on the acceptCount setting. The default value varies by connector type. For BIO the default is the value of maxThreads unless an Executor is used in which case the default will be the value of maxThreads from the executor. For NIO the default is 10000. For APR/native, the default is 8192.

……

acceptCount:

The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.

minSpareThreads:

The minimum number of threads always kept running. If not specified, the default of 10 is used.

我簡單理解就是：

maxThreads:Tomcat線程池最多能起的線程數；

maxConnections:Tomcat最多能併發處理的請求（鏈接）；

acceptCount:Tomcat維護最大的對列數；

minSpareThreads:Tomcat初始化的線程池大小或者說Tomcat線程池最少會有這麼多線程。

比較容易弄混的是maxThreads和maxConnections這兩個參數：

maxThreads是指Tomcat線程池作多能起的線程數，而maxConnections則是Tomcat一瞬間作多可以處理的併發鏈接數。好比maxThreads=1000，maxConnections=800，假設某一瞬間的併發時1000，那麼最終Tomcat的線程數將會是800，即同時處理800個請求，剩餘200進入隊列「排隊」，若是acceptCount=100，那麼有100個請求會被拒掉。
注意：根據前面所說，只是併發那一瞬間Tomcat會起800個線程處理請求，可是穩定後，某一瞬間可能只有不多的線程處於RUNNABLE狀態，大部分線程是TIMED_WAITING，若是你的應用處理時間夠快的話。因此真正決定Tomcat最大可能達到的線程數是maxConnections這個參數和併發數，當併發數超過這個參數則請求會排隊，這時響應的快慢就看你的程序性能了。

 

以上的結論都是我我的驗證和總結，若有不對，跪求指正！！！

 

==========================更新（2015-1-20）===========================

 

以上的得出結論有嚴重的問題，特此更正下，若是誤導了某些同窗十分抱歉。

主要錯誤的結論是：

• Tomcat不會主動對線程池進行收縮，除非肯定沒有任何請求的時候，Tomcat纔會將線程池收縮到minSpareThreads設置的大小；
• Tomcat6以前的版本有一個maxSpareThreads參數，可是在7中已經移除了，因此只要前面哪怕只有一個請求，Tomcat也不會釋放多於空閒的線程。

Tomcat會中止長時間閒置的線程。Tomcat還有一個參數叫maxIdleTime：

 (int) The number of milliseconds before an idle thread shutsdown, unless the number of active threads are less or equal to minSpareThreads. Default value is 60000(1 minute)

其實從這個參數解釋也能看出來Tomcat會中止閒置了超過必定時間的線程的，這個時間就是maxIdleTime。但我以前的測試中確實沒有發現線程釋放的現象，這是爲何呢？我發現除了這個參數線程池線程是否釋放？釋放多少？還跟當前Tomcat每秒處理的請求數（從Jmeter或LoadRunner來看能夠理解爲TPS）有關係。經過下表能夠清晰的看出來線程數，TPS和maxIdleTime之間的關係：

TPS	maxIdleTime（ms）	Thread Count
10	60,000	600
5	60,000	300
1	60,000	60

依次類推，固然Thread Count這一列是一個大約數，上下相差幾個，但基本符合這樣一個規則：

Thread Count = min(max((TPS * maxIdleTime)/1000,minSpareThreads),maxThreads)

固然這個Thread Count不會小於minSpareThreads，這個跟以前的結論仍是同樣的。我如今大膽猜想下（回頭看源碼驗證下，或者哪位同窗知道告訴我下，謝謝）：

Tomcat線程池每次從隊列頭部取線程去處理請求，請求完結束後再放到隊列尾部，也就是說先後兩次請求處理不會用同一個線程。某個線程閒置超過maxIdleTime就釋放掉。

假設首先線程池在高峯時期暴漲到1000，高峯事後Tomcat處理一次請求須要1s（從Jmeter看TPS大約就爲1），那麼在maxIdleTime默認的60s內會用到線程池中60個線程，那麼最後理論上線程池會收縮到60（假設minSpareThreads大於60）。另外：這個跟用不用Keep-Alive不要緊（以前測試結論是由於用了Keep-Alive致使程序性能降低，TPS下降了不少致使的）

 

這就是爲何我以前的測試中、還有咱們生產環境中線程數只增不減的緣由，由於就算峯值事後咱們的業務每秒請求次數仍然有100多，100*60=6000，也就是3000個線程每一個線程在被回收以前確定會被重用。

 

那麼如今有另一個問題，那麼正常狀況下爲何每秒100次的請求不會致使線程數暴增呢？也就是說線程暴增到3000的瓶頸到底在哪？這個我上面的結論其實也不是很準確。

真正決定Tomcat最大可能達到的線程數是maxConnections這個參數和併發數，當併發數超過這個參數則請求會排隊，這時響應的快慢就看你的程序性能了。

這裏沒說清楚的是併發的概念，無論什麼併發確定是有一個時間單位的（通常是1s），準確的來說應該是當時Tomcat處理一個請求的時間內併發數，好比當時Tomcat處理某一個請求花費了1s，那麼若是這1s過來的請求數達到了3000，那麼Tomcat的線程數就會爲3000，maxConnections只是Tomcat作的一個限制。

 

歡迎斧正！

 

補充：

使用Jmeter能夠很容易的控制請求的頻率。

Linux最大線程數限制及當前線程數查詢

一、總結系統限制有：     /proc/sys/kernel/pid_max #查系統支持的最大線程數，通常會很大，至關於理論值     /proc/sys/kernel/thread-max     max_user_process（ulimit -u） #系統限制某用戶下最多能夠運行多少進程或線程     /proc/sys/vm/max_map_count     硬件內存大小 二、Java虛擬機自己限制：     -Xms  #intial java heap size     -Xmx  #maximum java heap size     -Xss  #the stack size for each thread 三、查詢當前某程序的線程或進程數 pstree -p `ps -e | grep java | awk '{print $1}'` | wc -l 或 pstree -p 3660 | wc -l 四、查詢當前整個系統已用的線程或進程數 pstree -p | wc -l