Tomcat的性能優化及JVM內存工做原理

時間  2020-01-15
標籤 tomcat 性能 優化 jvm 內存 原理 欄目 Tomcat 简体版
原文   原文鏈接

JVM性能優化原則：代碼運算性能、內存回收、應用配置（影響Java程序主要緣由是垃圾回收機制）
代碼層優化：避免過多循環嵌套、調用和複雜邏輯。javascript

Tomcat調優主要內容

一、增長最大鏈接數css

二、調整工做模式html

三、啓用gzip壓縮java

四、調整JVM內存大小nginx

五、做爲web服務器時、無Apache整合或者nginxweb

六、合理選擇垃圾回收算法redis

七、儘可能使用較新的JDK版本算法

生產配置實例

<Connectorport="8080"protocol="org.apache.coyote.http11.Http11NioProtocol"     #調整工做模式爲NIO
           maxThreads="1000"              #最大線程數，默認150。這裏這是1000是爲了不隊列請求過多，致使響應過慢
           minSpareThreads="100"          #最小空閒線程數
           maxSpareThreads="200"          #最大空閒線程數，若是是超過這個數值，會自動關閉無用的線程
           acceptCount="900"              #當請求超過該值，便會將請求放到後面的隊列中等待
           disableUploadTimeout="true"    #禁止上傳超時時間
          connectionTimeout="20000"       #鏈接超時，單位毫秒，0表明不限制
           URIEncoding="UTF-8"            #URL地址編碼使用UTF-8
           enableLookups="false"          #關閉DNS解析，提升相應時間
           redirectPort="8443"            #重定向端口
           compression="on"               #啓用壓縮功能
          compressionMinSize="1024"       #最小壓縮大小，單位爲Byte（字節）
          compressableMimeType="text/html,text/xml,text/css,text/javascript"/>   #可支持壓縮的文件類型

Tomcat的運行模式

Tomcat有三種工做模式：Bio、Nio和Apr

Bio（Blocking I/O）：默認工做模式，一個線程處理一個請求，在高併發的的環境下，線程數較多，浪費資源，沒有任何優化技術處理，性能比較低數據庫

Nio（New I/O or Non-Blocking）:非阻塞式I/O模式，NIO主要是利用Java的異步I/O處理，能夠經過少許的線程處理大量的請求apache

Apr（Apache Portable Runtime，Apathe可移植運行庫）：Tomcat運行高併發應用的首選工做模式，APR是從操做系統層面解決IO阻塞問題，大幅度提升服務器的處理和響應性能

啓動Apr模式的方法

1）安裝依賴庫 

[root@tomcat ~]# yum install -y apr-devel openssl-devel gcc make

[root@tomcat ~]# rpm -qa | grep openssl
openssl-libs-1.0.2k-12.el7.x86_64
openssl-devel-1.0.2k-12.el7.x86_64
openssl-1.0.2k-12.el7.x86_64

2）安裝apr動態庫

在安裝apr動態庫以前，須要java環境，在這裏，有個坑須要注意，那就是ap在預編譯的以後必定要有jdk環境，咱們通常安裝都是直接yum install -y java一條命令搞定，可是呢，在這裏是不支持的，

須要手動配置才行，不然便會報錯

配置環境變量

export JAVA_HOME=/usr/java/jdk1.7.0_65
export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH:$HOMR/bin

下載Tomcat-native包

地址：https://archive.apache.org/dist/tomcat/tomcat-connectors/native/1.2.17/source/tomcat-native-1.2.17-src.tar.gz

[root@tomcat ~]# wget https://mirrors.tuna.tsinghua.edu.cn/apache/tomcat/tomcat-connectors/native/1.2.17/source/tomcat-native-1.2.17-src.tar.gz    #下載包

[root@tomcat ~]# tar zxvf tomcat-native-1.2.17-src.tar.gz -C /usr/local/tomcat/bin/      #解壓

[root@tomcat ~]# cd /usr/local/tomcat/bin/tomcat-native-1.2.17-src/native/     #移動到指定目錄
 
[root@tomcat native]# make && make install    #編譯安裝
[root@tomcat native]# ll /usr/local/apr/lib/    #查看是否成功
total 3268
-rw-r--r-- 1 root root 2121194 Jun 30 16:28 libtcnative-1.a
-rwxr-xr-x 1 root root 1027 Jun 30 16:28 libtcnative-1.la
lrwxrwxrwx 1 root root 23 Jun 30 16:28 libtcnative-1.so -> libtcnative-1.so.0.2.17
lrwxrwxrwx 1 root root 23 Jun 30 16:28 libtcnative-1.so.0 -> libtcnative-1.so.0.2.17
-rwxr-xr-x 1 root root 1204408 Jun 30 16:28 libtcnative-1.so.0.2.17
drwxr-xr-x 2 root root 4096 Jun 30 16:28 pkgconfig

配置APR本地庫到系統共享庫搜索路徑  # vim /usr/local/tomcat/bin/catalina.sh

JAVA_OPTS="$JAVA_OPTS -Djava.library.path=/usr/local/apr/lib/"   #在虛擬機啓動參數JAVA_OPTS中添加java.library.path參數，指定apr庫的路徑

實現原理：Tomcat利用基於Apr庫tomcat-native來實現操做系統級別控制，提供一種優化技術和非阻塞式I/O操做，大大提升併發處理能力。但須要安裝Apr和tomcat-native庫。

工做模式原理涉及了網絡I/O模型知識

阻塞式I/O模型：應用進程調用recv函數系統調用時，若是等待要操做的數據沒有發送到內核緩存區，應用進程將阻塞，不能接收其它請求。反以內核recv端緩衝區有數據，內核會把數據複製到用戶空間解除阻塞，繼續處理下一個請求。（內核空間（緩衝區)--用戶空間(系統調用)）

非阻塞式I/O模型：應用進程設置成非阻塞模式，若是要操做的數據沒有發到內核緩衝區，recv系統調用返回一個錯誤，應用進程利用輪詢方式不斷檢查此操做是否就緒，若是緩衝區有數據則返回，I/O操做同時不會阻塞應用進程，期間會繼續處理新請求。

I/O複用模型：阻塞發生在select/poll的系統調用上，而不是阻塞在實際的I/O系統調用上。能同時處理多個操做，並檢查操做是否就緒，select/epoll函數發現有數據就緒後，就經過實際I/O操做將數據複製到應用進程緩存區中。

異步I/O模型：應用進程通知內核開始第一個異步I/O操做，並讓內核在整個操做（包括數據複製緩衝區）完成後通知應用進程，期間會繼續處理新請求。

I/O操做分爲兩個階段：第一個階段等待數據可用，第二個階段將數據從內核複製到用戶空間。

前三種模型的區別：第一階段阻塞式I/O阻塞在I/O操做上，非阻塞式I/O輪詢，I/O複用阻塞在select/poll或epoll上。第二個階段都是同樣的。而異步I/O的兩個階段都不會阻塞進程。

Java性能問題主要來自JVM，JVM  GC也比較複雜，相關基礎概念

一、JVM內存劃分爲年輕代、老年代、永久代。

二、年輕代又分爲： Eden和Survivor區由FromSpace和ToSpace組成。Eden區佔大容量，Survivor兩個區佔小容量，默認比例大概是8:2。

三、堆內存（Heap）=年輕代+老年代。非堆內存=永久代。

四、堆內存用途： 存放的對象，垃圾收集器就是收集這些對象，而後根據GC算法回收。

五、非堆內存用途：JVM自己是用，存放一些類、方法、常量、屬性等。

六、年輕代： 新生成的對象首先放到年輕代的Eden區中，當Eden滿時，通過GC後，還存活的對象被複制到Survivor區的FromSpace中，若是Survivor區滿時，會再被複制到Survivor區的ToSpace區。若是還有存活對象，會再被複制到老年代。

七、老年代：在年輕代中通過GC後還存活的對象會被複制到老年代中。當老年代空間不足時，JVM會對老年代進行徹底的垃圾回收（Full GC）。若是GC後，仍是沒法存放從Survivor區複製過來的對象，就會出現OOM（Out of Memory）。

八、永久代：也成爲方法，存放靜態類型數據，好比類、方法、屬性等

垃圾回收（GC，garbage collection）算法

一、標記-清除（Mark-Sweep）

GC分爲兩個階段，標記和清除。首先標記全部可回收的對象，在標記完成後統一回收全部被標記的對象。同時會產生不連續的內存碎片。碎片過多會致使之後程序運行時須要分配較大對象時，沒法找到足夠的連續內存，而不得以再次觸發GC。

二、複製（copy）

將內存按容量劃分爲兩塊，每次只使用其中一塊。當着一塊用完了，就將存活的對象複製到另外一塊上，而後再把已使用的內存空間一次清理掉，這樣使得每次對半個內存區在回收，也不用考慮內存碎片問題，簡單高效。缺點須要兩倍的內存空間。

三、標記-整理（Mark-Compact）

也分爲兩個階段，首先標記可回收的對象，再將存活的對象都向一端移動，而後清理掉邊界之外的內存。此方法避免標記-清除算法的碎片問題，同時也避免了複製算法的空間問題。

通常年輕代中執行GC後，會有少許的對象存活，就會選用複製算法，只要付出少許的存貨成本就能夠完成收集。而老年代中因對象存活率高，沒有額外過多內存空間分配，就須要使用標記-清理或標記-整理算法來進行回收。

垃圾收集器

一、串行收集器（Serial）

比較老的收集器，單線程。收集時，必須暫停應用的工做線程，直到收集結束。

二、並行收集器（parallel）

多線程並行工做，在多核CPU下效率更高，應用線程依然處於等待狀態。

三、CMS收集器（concurrent Mark sweep）

  1. 初始標記（Initial Mark）

  2. 併發標記（Concurrent Mark）

  3. 從新標記（Remark）

  4. 併發清除（Concurrent Sweep）

初始標記、從新標記這兩個步驟仍然須要暫停應用線程。初始標記只是標記一下GC Roots能直接關聯的對象，速度很快，併發標記階段是標記可回收對象，而從新標記階段則是爲了修正併發標記期間因用戶程序繼續運行致使
標記產生變更的那一部分對象的標記記錄，這個階段暫停時間比初始標記階段稍長一點，但遠比並發標記時間段。

因爲整個過程當中消耗最長的併發標記和併發清除過程收集器線程均可以與用戶線程一塊兒工做，因此，CMS收集器內存回收與用戶一塊兒併發執行的，大大減小了暫停時間。

四、G1收集器（Garbage First）
G1收集器將堆內存劃分多個大小相等的獨立區域（Region），而且能預測暫停時間，能預測緣由它能避免對整個堆進行全區收集。G1跟蹤各個Region裏的垃圾堆積價值大小（所得到空間大小以及回收所需時間），在後臺維護一個優先列表，每次根據容許的收集時間，優先回收價值最大的Region，從而保證了再有限時間內得到更高的收集效率。

G1收集器工做工程分爲4個步驟，包括：

初始標記（Initial Mark）

併發標記（Concurrent Mark）

最終標記（Final Mark）

篩選回收（Live Data Counting and Evacuation）

初始標記與CMS同樣，標記一下GC Roots能直接關聯到的對象。併發標記從GC Root開始標記存活對象，這個階段耗時比較長，但也能夠與應用線程併發執行。而最終標記也是爲了修正在併發標記期間因用戶程序繼續運做而致使標記產生變化的那一部分標記記錄。最後在篩選回收階段對各個Region回收價值和成本進行排序，根據用戶所指望的GC暫停時間來執行回收。

瞭解了JVM基礎知識，下面配置下相關Java參數，將下面一段放到catalina.sh裏面：

JAVA_OPTS="-server -Xms1024m -Xmx1536m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParallelGCThreads=8 XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:-PrintGC -XX:-PrintGCDetails -XX:-PrintGCTimeStamps -Xloggc:../logs/gc.log"
-Xms

堆內存初始大小，單位m、g

-Xmx

堆內存最大容許大小，通常不要大於物理內存的80%

-XX:PermSize

非堆內存初始大小，通常應用設置初始化200m，最大1024m就夠了

-XX:MaxPermSize

非堆內存最大容許大小

-XX:+UseParallelGCThreads=8

並行收集器線程數，同時有多少個線程進行垃圾回收，通常與CPU數量相等

-XX:+UseParallelOldGC

指定老年代爲並行收集

-XX:+UseConcMarkSweepGC

CMS收集器（併發收集器）

-XX:+UseCMSCompactAtFullCollection

開啓內存空間壓縮和整理，防止過多內存碎片

-XX:CMSFullGCsBeforeCompaction=0

表示多少次Full GC後開始壓縮和整理，0表示每次Full GC後當即執行壓縮和整理

-XX:CMSInitiatingOccupancyFraction=80%

表示老年代內存空間使用80%時開始執行CMS收集，防止過多的Full GC

注意：不是JVM內存設置越大越好，具體仍是根據項目對象實際佔用內存大小而定，能夠經過Java自帶的分析工具來查看。若是設置過大，會增長回收時間，從而增長暫停應用時間。

gzip壓縮做用：節省服務器流量和提升網站訪問速度。客戶端請求服務器資源後，服務器將資源文件壓縮，再返回給客戶端，由客戶端的瀏覽器負責解壓縮並瀏覽。

使用Apache與Tomcat整合，由於Tomcat處理靜態文件能力遠不足Apache，所以讓Apache來處理靜態文件，Tomcat處理動態jsp文件，能夠有效提升處理速度。

TomcatSessionID持久化三種方法：

Session粘性：經過瀏覽器Cookie綁定SessionID，經過sticky模式將同一Session請求分配到同一Tomcat上。

Session複製：Tomcat經過廣播形式將Session同步到其餘Tomcat節點，而且Linux下要手動開啓開放廣播地址。不易後端節點過多

Session保存數據庫（memcache、redis）：將SessionID保存在共享的數據庫中。

OOM（Out of Memory）異經常見有如下幾個緣由：

1）老年代內存不足:
java.lang.OutOfMemoryError:Javaheapspace

2）永久代內存不足：

java.lang.OutOfMemoryError:PermGenspace

3）代碼bug，佔用內存沒法及時回收。

前兩種狀況經過加大內存容量，能夠獲得解決。若是是代碼bug，就要經過jstack、jmap、jstat自帶的工具分析問題，定位到相關代碼，讓開發解決。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程