Tomcat重啟負載高問題定位

某產品每次重啟Tomcat都會收到CPU告警信息，重啟階段CPU使用率可以達到80%~90%以上，會持續一段時間回降（具體時間沒有考察）。應產品方要求，對該問題進行分析定位。 因線上產品不能隨便重啟，問題定位階段使用的是同規格的雲主機QA19，該環境上有和線上一致的應用程序，且重啟tomcat時，也會有CPU飙高的現象。 負載高的原因： 重啟的時候對資源使用情況進行監控，並通過top -H + jstack 分析消耗CPU過高的線程堆棧信息。

• 通過監控重啟時的資源使用情況，在qa19這台機器上，重啟一次，CPU飙高的持續時間約為50-60s左右。
• 通過top -H + jstack 定位消耗CPU過高的線程，發現有三個：

1. spring applicationContext在web容器中加載過程 消耗的資源：（部分堆棧信息）

"main" prio=10 tid=0x000000004166f800 nid=0x100f runnable [0x00007fbf42987000]
java.lang.Thread.State: RUNNABLE
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:384)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4206)
at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)

2. 兩個編譯線程：

"C2 CompilerThread1" daemon prio=10 tid=0x00007fec48001800 nid=0x13c4 runnable
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" daemon prio=10 tid=0x00000000407c1000 nid=0x13c3 runnable
java.lang.Thread.State: RUNNABLE

嘗試的解決方法： helloJava的兩篇文章中給出了兩種配置方法：見：http://hellojava.info/?p=195 以及 http://hellojava.info/?p=201

• 嘗試加上-XX:+TieredCompilation，期望借助多層編譯來緩解這個問題:

在tomcat jvm參數中增加該配置項，資源監控CPU飙高持續時間降低到45s左右，比原來少了10s+，略有效果

• 嘗試加一個-XX:CICompilerCount參數來試試，這個值默認是2，也就是說2個c2的編譯線程來進行編譯：

因為QA19和線上tomcat應用服務器都是2個核的雲主機，所以默認值2應該是最優值，嘗試把該值改成1 or 4，沒有起到優化效果。 存在問題： 對於QA19性能測試環境來說，重啟後沒有其他請求引入，但是線上環境重啟後會不斷有請求過來，所以CPU飙高的時間會持續時間更長。 對於性能測試環境，重啟之後的進行第一次並發測試，前期負載同樣會很高，如下圖： 同樣，在測試開始後通過top -H + jstack分析堆棧信息，分析得到兩個原因：

1. 啟動各種各樣的線程進行處理請求，如AJP線程、和數據通信的線程、和ActiveMQ通信的線程等，會短時間內耗費一些資源
2. 另外，測試剛啟動時，"C2 CompilerThread1"該線程耗費資源過多，會一段時間內持續在40%~80%的CPU消耗

測試時，增加-XX:+TieredCompilation該參數，對比資源使用情況如下：

• 並發50個線程時，增加參數之前（左圖）和增加參數後（右圖）

• 並發100個線程，增加參數前（左圖）和增加參數後（右圖）

結論： 可以看出即便有流量引入，-XX:+TieredCompilation該參數也是起到了一定作用，使得飙高的CPU盡快回落。 附錄：

-XX:+TieredCompilation

Enables a JIT compilation policy to make initial quick JIT compilation decisions analogous to optimizations made by the HotSpot VM’s -client runtime and then continue to make more sophisticated JIT compilation decisions similar to those made by the VM’s -server runtime for frequently called Java methods in the program. In short, it uses a combination of the best of both -client and -server runtimes, quick compilation along sophisticated optimizations for frequently called Java methods. At the time of this writing, it is not recommended to use this command line option as a replacement for the -server runtime since the -server runtime offers better peak performance. This recommendation may change in the future as the tiered compilation feature is enhanced. Client applications running Java 6 Update 25 or later may consider using this command line option with the -server runtime (-server -XX:+TieredCompilation) as an alternative to the -client runtime. It is recommended you measure application startup performance and application responsiveness to assess whether the -server runtime with -XX:+TieredCompilation is better suited for the application than the -client runtime.

<pne-width: 0px;="" margin-top:="" line-height:="" 22px;="" border-top-width:="" 0px"="">http://www.techpaste.com/2012/02/java-command-line-options-jvm-performance-improvement/