tomcat8性能優化

工做中項目的緣由，項目雲上貴州服務器有時候支撐不起過高的併發量，並且又沒那麼快更換更優的服務器，因此只能從tomcat上去作一些優化了。

tomcat優化我是從兩個地方入手，一個就是server.xml，還有一個就是catalina.sh。

server.xml

找到tomcat->conf下的server.xml

1. 先來看一個tomcat的線程池，默認的：

<!-- <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="150" minSpareThreads="4"/> -->
複製代碼

這裏默認是註釋掉的，咱們修改成：

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="900" minSpareThreads="100" maxSpareThreads="500" prestartminSpareThreads="true" maxQueueSize="300" />
複製代碼

• maxThreads：最大併發數，默認爲200，通常設置在600-900
• minSpareThreads：最小備用線程數，tomcat初始化時建立的線程，默認爲25
• maxSpareThreads：最大備用線程數
• prestartminSpareThreads：在Tomcat初始化的時候就初始化 minSpareThreads 的參數值，若是不等於 true，minSpareThreads的值就沒啥效果了
• maxQueueSize：最大的等待隊列數，超過則拒絕請求

1. 修改連接參數：
   默認的是：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
複製代碼

默認的是http協議的，咱們這裏先將tomcat設置成了https協議：

<Connector port="9090" 
      protocol="org.apache.coyote.http11.Http11Nio2Protocol"
      maxThreads="10000"
      SSLEnabled="true"
      scheme="https"
      secure="true"
      keystoreFile="cert/wtm-ssl.pfx"
      keystorePass="111"
      keystoreType="PKCS12"
      useBodyEncodingForURI="true"
      clientAuth="false"
      sslProtocol="TLS"
      connectionTimeout="20000"
      redirectPort="8443"

複製代碼

需不須要改爲https協議按業務來分，在此基礎上接着：

executor="tomcatThreadPool"
      maxConnections="900"
      enableLookups="false"
      acceptCount="700"
      maxPostSize="10485760"
      disableUploadTimeout="true"
      compression="on"
      compressionMinSize="2048"
      maxProcessors="1000"
      minProcessors="5"         
      compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript"
      URIEncoding="UTF-8"
/>
複製代碼

首先要執行以前配置的tomcat線程池

• maxConnections：最大鏈接數
• enableLookups：禁用DNS查詢，爲了提升性能，設置爲false
• acceptCount：當線程數達到maxThreads後後續請求會被放入一個等待隊列，這個acceptCount就是這個隊列的大小，默認爲100
• maxPostSize：以FORM URL參數方式提交post請求，限制提交最大的大小，默認2097152字節（2M）
• disableUploadTimeout：相似於Apache中的keeyalive同樣,是否須要tomcat容器單獨設置上傳時間限制，這裏是不用，仍是使用標準的，不去給上傳的附件單獨作超時設置
• compression：設置是否開啓GZip壓縮HTTP 壓縮
• compressionMinSize：啓用壓縮的輸出內容大小，這裏面默認爲2KB
• maxProcessors：線程共享地址空間
• minProcessors：線程共享地址空間
• compressableMimeType：須要壓縮的類型

catalina.sh

在tomcat/bin/catalina.sh文件中，將下列添加到文件第一行：
若是服務器只運行一個tomcat

• 內存4G：

CATALINA_OPTS="-Dfile.encoding=UTF-8 -server -Xms2048m -Xmx2048m -Xmn1024m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:SurvivorRatio=10 -XX:MaxTenuringThreshold=15 -XX:NewRatio=2 -XX:+DisableExplicitGC"
複製代碼

• 內存8G：

CATALINA_OPTS="-Dfile.encoding=UTF-8 -server -Xms4096m -Xmx4096m -Xmn2048m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:SurvivorRatio=10 -XX:MaxTenuringThreshold=15 -XX:NewRatio=2 -XX:+DisableExplicitGC"
複製代碼

• 內存16G：

CATALINA_OPTS="-Dfile.encoding=UTF-8 -server -Xms8192m -Xmx8192m -Xmn4096m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:SurvivorRatio=10 -XX:MaxTenuringThreshold=15 -XX:NewRatio=2 -XX:+DisableExplicitGC"
複製代碼

• 內存32G：

CATALINA_OPTS="-Dfile.encoding=UTF-8 -server -Xms16384m -Xmx16384m -Xmn8192m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:SurvivorRatio=10 -XX:MaxTenuringThreshold=15 -XX:NewRatio=2 -XX:+DisableExplicitGC"
複製代碼

參數說明：

• -Dfile.encoding：默認文件編碼
• -server：表示這是應用於服務器的配置，JVM 內部會有特殊處理的
• -Xmx1024m：設置JVM最大可用內存爲1024MB
• -Xms1024m：設置JVM最小內存爲1024m。此值能夠設置與-Xmx相同，以免每次垃圾回收完成後JVM從新分配內存。
• -Xmn1024m：設置JVM新生代大小（JDK1.4以後版本）。通常-Xmn的大小是-Xms的1/2左右，不要設置的過大或太小，過大致使老年代變小，頻繁Full GC，太小致使minor GC頻繁。若是不設置-Xmn，能夠採用-XX:NewRatio=2來設置，也是同樣的效果
• -XX:NewSize：設置新生代大小
• -XX:MaxNewSize：設置最大的新生代大小
• -XX:PermSize：設置永久代大小
• -XX:MaxPermSize：設置最大永久代大小
• -XX:NewRatio=4：設置年輕代（Eden和兩個Survivor）與終身代的比值（去除永久代）
• -XX:MaxTenuringThreshold=10：設置垃圾最大年齡，默認爲：15。若是設置爲 0 的話，則年輕代對象不通過 Survivor 區，直接進入年老代。對於年老代比較多的應用，能夠提升效率。
• -XX:+DisableExplicitGC：這個將會忽略手動調用 GC 的代碼使得 System.gc() 的調用就會變成一個空調用，徹底不會觸發任何 GC

JVM的垃圾回收機制：

jvm的內存分爲2類，一個是perm型，一個是generation型。perm區域存放的是class這些靜態信息，通常默認爲64m，若是項目很大，有可能已啓動就會報錯：out of memory permsize。從新設置一下permsize就能夠解決。

而generation區域，應用代碼基本在這個區域活動，new的類都會在這個區域，並且jvm的絕大部分工做也在這裏。大體理解一下：

這個區域區域包含新生代和老生代區域，全部new出來的會放置在新區域，而屢次回收失敗的一些一直被使用的實例則會被轉移到老生代，因此新生代區域的活動很頻繁。新生代內存不足會觸發一次這個區域的GC---而後再到老生代GC---最後FULL GC。FULL GC代價很高，應儘可能避免，儘可能在newsize參數的這個區gc，通常配置 newsize分配到總內存1／4左右，－－－最終，若是full gc 仍是內存不足，那就會引起out of memory 常見的那種。