tomcat調優配置

今天遇到一個tomcat服務註冊後配置Java參數沒效果，最後在註冊表中刪除原來的tomcat服務後，順便看了一下tomcat的調優配置，看別人總結的不錯，就轉載一下。

Tomcat、Jetty、GlassFish 等等這系列 Web容器/應用服務器，雖然作爲容器，提供的是一個 Java Web 的運行時環境，以支持Servlet/JSP 等等這些內容的運行，但咱們都很清楚，其本質上仍是一個 Java 應用程序。 每次對於 容器的啓動運行，都是把這個 Java 程序跑起來，來實現 Web 容器的能力。

 

作爲一類「特殊」的 Java 應用程序，和任務其餘的 Java 應用同樣，須要使用到JVM，會有堆，會使用到垃圾回收，會涉及到不一樣的堆分區比例...  

所以在對Web 容器( 應用服務器) 的調優中必不可少的是對於 JVM 的調優。

 

 

對於 JVM 的調優，主要有兩個方面考慮：

 

內存大小配置

垃圾回收算法選擇

 

固然，確切的說，以上兩點並不互相獨立，內存的大小配置也會影響垃圾回收的執行效率。

 

其中內存大小配置，最主要作的有

 

肯定內存佔用的總大小

肯定內存中各個代(Gen) 的大小劃分

 

 

內存大小配置

 

所謂內存大小的佔用，是指應用程序啓動後穩定運行一小段時間時，觀察到的內存佔用狀況。

以 HotSpot 虛擬機爲例，Java 堆主要有三個空間：

新生代、老年代和永久代。 

 

根據不一樣應用的特別，觀察應用對於內存的佔用，若是有大量的臨時對象，不會重複使用，則能夠調整 New Gen， 這樣這些臨時對象就在新生代建立完成，並在 Minor GC 產生時被回收，這樣較短生存活的對象不會晉升到老年代，從而能夠避免垃圾堆集產生 Full GC。 

 

理想狀態下，短時間存活的對象都只在新生代完成生命週期，被費時勁少的 

Minor GC 回收完成， 而長期存活，將會屢次使用的在屢次回收以後晉升到老年代， 最終通過 Full GC 完成生命週期。

 

這裏涉及到關於內存大小的調整參數有：

 

-Xms

-Xmx

 

這兩個參數用於配置 heap 的起始大小和最大值。這裏須要通過觀察，找一個合適的值，設置太大會致使內存浪費，同時也會致使垃圾回收耗時太長。對於 Tomcat 來講，通常都會將初始值和最大值設置爲相同值，這樣就避免在初始內存不足時觸發 Full GC 來進行擴展內存。

 

設定 heap 大小以後，要根據對象生命週期的特徵，來調整新生代與老年代的大小比例。

 

涉及到的參數有：

-XX:NewSize

-XX:NewRatio

-XX:MaxNewSize

-Xmn

 

第一個是直接設置新生代初始大小，第二個是設置比例(Ratio)。過高或過低都會致使 GC 不能高效的工做。畢竟 Minor GC 也是要耗時的。最後一個設置新生代的初始值和最大值相同，堆空間的變化不影響其值。

 

對於使用了大量第三方類庫的應用來講，會加載許多框架依賴的類，使用過程當中可能會遇到由於Perm Gen 不足產生的 OOM，這種狀況能夠經過觀察穩定狀態下 Perm 區的佔用，再經過參數設置。

 

-XX:PermSize

-XX:MaxPermSize

-XX:MaxMetaspaceSize

 

第一個會設置Perm區的初始大小，第二個用於設置Perm 區的最大值。在Java 8的時候， Perm 區被移除，改成Metaspace，不過若是遇到相似的OOM,依然能夠調整其大小。

 

此外，對於使用大量線程的應用，也能夠配置 -Xss，主要用於設置單個線程的stack 大小。注意，是單個的大小，所以設置值越大，會佔用越大，可用的線程數也就越少。

 

這裏的配置通常對於-X開始的能夠直接在後面用數字加單位，而-XX的則須要等號後數字再加單位，例如：

java -Xms100m -Xmx200m -XX:PermSize=300m

 

這裏數字後的單能夠是m,g,k表明計算機中的不一樣單位。

 

那咱們前面一直在說根據不一樣的應用，觀察分析設置堆的大小，堆的各個代的大小，那具體觀察什麼呢？

 

咱們通常在JVM的配置中增長一些打印 GC 日誌的選項，配置方式和上面的相似，這樣在 GC 產生時，會打印出各個代佔用的大小，具體觸發時間等。推薦的配置有如下幾個：

 

-XX:+PrintGCTimeStamps

-XX:+PrintGCDetails

-Xloggc:<文件名>

-XX:PrintGCDateStamps

 

第一個和第四個選項能夠任選一個，第一個打印自JVM啓動以來的時間，通常也稱爲uptime, 第四個打印的是系統當前日期和時間。

 

根據 GC 日誌產生的內容，來觀察具體的大小，開始使用上述的配置參數進行調整。固然，也能夠用 JConsole, JVisual VM 這些工具可視化的進行了解再調整。工具的使用能夠參考歷史文章

Java七武器系列多情環 --多功能Profiling工具 JVisual VM

 

 

垃圾回收算法

 

不一樣的垃圾回收算法，對於應用的影響很大。一方面可能在一個服務器上卻使用了單線程的回收算法，也可能應用對於響應要求很高，但卻使用了一個吞吐量優先的算法，致使響應太慢。

因此對於垃圾回收算法的選擇，通常都是根據應用的特色，是要低延遲仍是高吞吐量，選擇合適的算法。咱們前面也提到，垃圾回收算法和內存的大小配置並不是獨立的，內存設置大是回收的頻率會下降，但每次的執行時間也會變長。因此這裏也是一個須要權衡的地方。

 

延遲、吞吐量調優

其餘 JVM 配置

 

垃圾回收算法對應到的就是不一樣的垃圾收集器，具體到在 JVM 中的配置，是使用 -XX:+UseParallelOldGC 或者 -XX:+UseConcMarkSweepGC 這種不一樣的收集器來達到選擇算法的目的。

 

其中 ParallelGC 也稱爲 吞吐量優先收集器，能夠提高應用的吞吐量，但在老年代大小調整之，進行幾回垃圾回收後，不能知足應用的低延遲要求。

通常經常使用到ConcMarkSweepGC， 也稱之爲 CMS GC，其能夠作到老年代的垃圾回收與應用程序的純種並行執行，因此能夠實現低延遲。

 

這裏注意，因爲 CMS GC 和其餘GC回收算法使用的框架不一樣，所以不能混用，在使用CMS 進行老年代回收時，新生代默認使用了單線程回收算法，此時能夠經過配置 -XX:+UseParNewGC來使用 新生代並行回收。

 

因爲CMS是垃圾回收和應用線程並行，所以須要額外的CPU處理資源，若是隻有一個CPU的機器，或者有多個忙碌的CPU，又想要使用低延遲的收集器，此時能夠經過配置 CMS 收集器的增量模式來進行回收，經過指定 -XX:+CMSIncrementalMode 來開啓增量模式。此時交替運行垃圾收集器應用線程。經過配置 

-XX:CMSIncrementalSafetyFactor=X， -XX:CMSIncrementalDutyCycleMin=Y,

-XX:CMSIncrementalPacing 能夠控制垃圾收集後臺線程爲應用線程讓出多少CPU週期。

 

參數-XX:+CMSParallelRemarkEnabled 用來下降標記停頓，另外因爲CMS 回收後的老年代內存空間並非連續的，所以經過參數

-XX:+UseCMSCompactAtFullCollection 在Full GC的時候對年老代的壓縮。

 

在JDK1.7 的時候引入了 G1 收集器，能夠經過配置-XX:+UseG1GC 來開啓。這一方面的實戰經驗很少，有相關使用經驗的朋友歡迎分享。

 

此外，還能夠對新生代進行更細緻的配置，好比設置Eden 和 Suvivor 區的比例等，和Newxx相似，能夠經過SuvivorRation設置比例。

 

 

其餘 JVM 配置

 

可使用 -XX:+DisableExplicitGC 選項來禁止顯式的 System.gc 的調用。這個使用時須要評估後再使用。

 

所謂調優，就是一個不斷調整和優化的過程，須要觀察、配置、測試再如此重複。有相關經驗的朋友歡迎留言補充！

 

說到底，那上面的這些選項是要配置在哪裏呢？ 咱們前面提到 Tomcat 本質也是個普通的 Java 應用，所以和通常的 Java 啓動方式相似，也是相似 

 

java -Xms100m -XX:+UseParallelOldGC 應用主類

 

經過這種形式來啓動，區別只是 Tomcat 將上述命令放到了文件中，對應到不一樣的操做系統，Windows下使用 bat文件， Linux下使用 sh 文件。

 

因此咱們的配置項也是加到這些文件中。

 

咱們來看catalina.sh中實際啓動時執行的命令：

 

 

 

因此咱們的選項能夠加到 

JAVA_OPTS

CATALINA_OPTS

這些可選項中。

配置比較簡單，例以下面這樣：

 

 

配置的時候須要特別注意的是，不要把前面已經有的配置沖掉，好比

在配置JAVA_OPTS的時候，要把前面已經配置的加上，寫起來是這樣：

JAVA_OPTS="$JAVA_OPTS 新增的內容"