作者:Java架構師歷程
來源:cloud.tencent.com/developer/article/1346964
Tomcat性能調優(yōu)
找到Tomcat根目錄下的conf目錄,修改server.xml文件的內容。對于這部分的調優(yōu),我所了解到的就是無非設置一下Tomcat服務器的最大并發(fā)數(shù)和Tomcat初始化時創(chuàng)建的線程數(shù)的 設置,當然還有其他一些性能調優(yōu)的設置,下圖是我根據(jù)我機子的性能設置的一些參數(shù)值,給各位詳細解釋一下吧:
1、URIEncoding=“UTF-8”:設置Tomcat的字符集。這種配置我們一般是不會設置的,因為關于亂碼的轉換我們會在具體項目中具體處理,直接修改Tomcat的字符集未免過于太死板。
2、maxThreads=“300”:設置當前Tomcat的最大并發(fā)數(shù)。Tomcat默認配置的最大請求數(shù)是150個,即同時能支持150個并發(fā)。但是在實際運用中,最大并發(fā)數(shù)與硬件性能和CPU數(shù)量都有很大關系的,更好的硬件、更高的處理器都會使Tomcat支持更多的并發(fā)數(shù)。如果一般在實際開發(fā)中,當某個應用擁有 250 個以上并發(fā)的時候,都會考慮到應用服務器的集群。
3、minSpareThreads=“50”:設置當前Tomcat初始化時創(chuàng)建的線程數(shù),默認值為25。
4、acceptCount=“250”:當同時連接的人數(shù)達到maxThreads參數(shù)設置的值時,還可以接收排隊的連接數(shù)量,超過這個連接的則直接返回拒絕連接。指定當任何能夠使用的處理請求的線程數(shù)都被使用時,能夠放到處理隊列中的請求數(shù),超過這個數(shù)的請求將不予處理。默認值為100。在實際應用中,如果想加大Tomcat的并發(fā)數(shù) ,應該同時加大acceptCount和maxThreads的值。
5、enableLookups=“false”:是否開啟域名反查,一般設置為false來提高處理能力,它的取值還有true,一般很少使用。
6、maxKeepAliveRequests=“1”:nginx動態(tài)的轉給tomcat,nginx是不能keepalive的,而tomcat端默認開啟了keepalive,會等待keepalive的timeout,默認不設置就是使用connectionTimeout。所以必須設置tomcat的超時時間,并關閉tomcat的keepalive。否則會產生大量tomcat的socket timewait。
maxKeepAliveRequests=”1”就可以避免tomcat產生大量的TIME_WAIT連接,從而從一定程度上避免tomcat假死。
JVM性能調優(yōu)
Tomcat本身還是運行在JVM上的,通過對JVM參數(shù)的調整我們可以使Tomcat擁有更好的性能。目前針對JVM的調優(yōu)主要有兩個方面:內存調優(yōu)和垃圾回收策略調優(yōu)。
一、內存調優(yōu)
找到Tomcat根目錄下的bin目錄,設置catalina.sh文件中JAVA_OPTS變量即可,因為后面的啟動參數(shù)會把JAVA_OPTS作為JVM的啟動參數(shù)來處理。再說Java虛擬機的內存結構是有點復雜的,相信很多人在理解上都是很抽象的,它主要分為堆、棧、方法區(qū)和垃圾回收系統(tǒng)等幾個部分組成,下面是我從網(wǎng)上扒的內存結構圖:
內存調優(yōu)這塊呢,無非就是通過修改它們各自的內存空間的大小,使應用能夠更加合理的運用,下圖是我根據(jù)我機子的性能設置的參數(shù),給各位詳細解釋一下各個參數(shù)的含義吧:
1、-Xmx512m:設置Java虛擬機的堆的最大可用內存大小,單位:兆(m),整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m。堆的不同分布情況,對系統(tǒng)會產生一定的影響。盡可能將對象預留在新生代,減少老年代GC的次數(shù)(通常老年回收起來比較慢)。
實際工作中,通常將堆的初始值和最大值設置相等,這樣可以減少程序運行時進行的垃圾回收次數(shù)和空間擴展,從而提高程序性能。
2、-Xms512m:設置Java虛擬機的堆的初始值內存大小,單位:兆(m),此值可以設置與-Xmx相同,以避免每次垃圾回收完成后JVM重新分配內存。
3、-Xmn170m:設置年輕代內存大小,單位:兆(m),此值對系統(tǒng)性能影響較大,Sun官方推薦配置為整個堆的3/8。一般在增大年輕代內存后,也會將會減小年老代大小。
4、-Xss128k:設置每個線程的棧大小。JDK5.0以后每個線程棧大小為1M,以前每個線程棧大小為256K。更具應用的線程所需內存大小進行調整。 在相同物理內存下,減小這個值能生成更多的線程。但是操作系統(tǒng)對一個進程內的線程數(shù)還是有限制的,不能無限生成,經(jīng)驗值在3000~5000左右。
5、-XX:NewRatio=4:設置年輕代(包括Eden和兩個Survivor區(qū))與年老代的比值(除去持久代)。設置為4,則年輕代與年老代所占比值為1:4,年輕代占整個堆棧的1/5 。
6、-XX:SurvivorRatio=4:設置年輕代中Eden區(qū)與Survivor區(qū)的大小比值。設置為4,則兩個Survivor區(qū)與一個Eden區(qū)的比值為2:4,一個Survivor區(qū)占整個年輕代的1/6。
7、-XX:MaxPermSize=16m:設置持久代大小為16m,上面也說了,持久代一般固定的內存大小為64m。
8、-XX:MaxTenuringThreshold=0:設置垃圾最大年齡。 如果設置為0的話,則年輕代對象不經(jīng)過Survivor區(qū),直接進入年老代。對于年老代比較多的應用,可以提高效率。
如果將此值設置為一個較大值,則年輕代對象會在Survivor區(qū)進行多次復制,這樣可以增加對象再年輕代的存活時間,增加在年輕代即被回收的概論。
二、垃圾回收策略調優(yōu)
找到Tomcat根目錄下的bin目錄,也是設置catalina.sh文件中JAVA_OPTS變量即可。我們都知道Java虛擬機都有默認的垃圾回收機制,但是不同的垃圾回收機制的效率是不同的,正是因為這點我們才經(jīng)常對Java虛擬機的垃圾回收策略進行相應的調整。下面也是通過我的一些需求來配置的垃圾回收策略:
Java虛擬機的垃圾回收策略一般分為:串行收集器、并行收集器和并發(fā)收集器。
串行收集器:
1、-XX:+UseSerialGC:代表垃圾回收策略為串行收集器,即在整個掃描和復制過程采用單線程的方式來進行,適用于單CPU、新生代空間較小及對暫停時間要求不是非常高的應用上,是client級別默認的GC方式,主要在JDK1.5之前的垃圾回收方式。
并發(fā)收集器:
1、-XX:+UseParallelGC:代表垃圾回收策略為并行收集器(吞吐量優(yōu)先),即在整個掃描和復制過程采用多線程的方式來進行,適用于多CPU、對暫停時間要求較短的應用上,是server級別默認采用的GC方式。此配置僅對年輕代有效。該配置只能讓年輕代使用并發(fā)收集,而年老代仍舊使用串行收集。
2、-XX:ParallelGCThreads=4:配置并行收集器的線程數(shù),即:同時多少個線程一起進行垃圾回收。此值最好配置與處理器數(shù)目相等。
3、-XX:+UseParallelOldGC:配置年老代垃圾收集方式為并行收集。JDK6.0支持對年老代并行收集 。
4、-XX:MaxGCPauseMillis=100:設置每次年輕代垃圾回收的最長時間,如果無法滿足此時間,JVM會自動調整年輕代大小,以滿足此值。
5、-XX:+UseAdaptiveSizePolicy:設置此選項后,并行收集器會自動選擇年輕代區(qū)大小和相應的Survivor區(qū)比例,以達到目標系統(tǒng)規(guī)定的最低相應時間或者收集頻率等,此值建議使用并行收集器時,一直打開。
并發(fā)收集器:
1、-XX:+UseConcMarkSweepGC:代表垃圾回收策略為并發(fā)收集器。 好了,到此我對虛擬機的垃圾回收策略總結就這么多,還是這句話:優(yōu)化的學習一直在路上,下面還有一張從其他博客中偷到的圖,據(jù)說以上三種GC機制是需要配合使用的。
特別推薦一個分享架構+算法的優(yōu)質內容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!