linux系統上關於tomcat監控,很多平臺只是監控端口判斷服務正常,忽略對tcp鏈接情況(監控項中應定義zabbix-agentd關於tcp連接監控),tomcat父進程是否僵死,如果不做監控檢查機制,在衆多的應用服務器,使用集羣負載,依然存在某個tomcat線程堆積,造成服務僵死,變現爲死套接字不斷增加無法釋放,但是服務還在,如果用了zabbix監控使用現成的模塊jmx監控
tomcat監控項
1、tomcat的應用端口(如8080),比較有侷限性
2、tomcat的jmx監控,是tomcat的性能監控。堆內存大小、線程峯值
3、tomcat可以寫個靜態文件 curl -I URL,獲取報文頭的http返回碼200則爲正常。
########## 方法在下面 ##########
------------------- JMX 監控 tomcat --------------
在tomcat被監控端安裝jdk和tomcat環境,然後在tomcat的安裝目錄的bin目錄下的catalina.sh文件
#需要進行用戶驗證
# ----- Execute The Requested Command -----------------------------------------”
之前插入新的一行(中間沒有換行)
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Djava.rmi.server.hostname=192.168.182.5"
==================================================================================
注意事項
1,-Djava.rmi.server.hostname=192.168.182.5中的IP地址要寫成本機配置的IP,也可以配置成0.0.0.0,不然有可能會導致監聽不能正常啓動。
使用JConsole監控本地應用程序在開發和創建原型是非常有效的,但不推薦用戶生產環境,因爲JConsole本省也消耗大量的系統資源
2,每個tomcat的端口不要重複,例如,一個ip上有多個tomcat實例,每個實例一個端口
=====================================================================================
在重啓tomcat服務前必須保證在hosts中有ip和主機名的映射。
在jdk的安裝目錄下認證用戶,配置用戶權限
編輯jmxremote.access和jmxremote.password 在jdk的安裝目錄下
which java
cd /usr/local/jdk/jre/lib/management
cp jmxremote.password.template jmxremote.password
chmod 600 jmxremote.access jmxremote.password
cp jmxremote.password.template jmxremote.password /opt/tomcat/tomcat1/conf/
cd /opt/tomcat/tomcat1/conf/
chmod 600 jmxremote.access jmxremote.password
vi jmxremote.password ---jdk 與 tomcat的jmxremote.password都修改
在jmxremote.password文件中,取消註釋,或者 加入自己的用戶名和密碼
monitorRole QED
controlRole R&D
在jmxremote.access 取消註釋
monitorRole readonly
controlRole readwrite \
create javax.management.monitor.*,javax.management.timer.* \
unregister
重啓tomcat服務
可以使用netstat -an | grep 9999命令查看端口是否正常啓動。可以看到端口9999的網絡連接
開始配置終端,獲取本機windows客戶端ip,linux機器執行 export DISPLAY=10.35.40.26:0.0(這是我的windowsIP,待會兒要開啓圖形化界面,如果是linux機器是本機虛擬機,那麼IP應該寫LINUX的IP的網關 192.168.182.1)
打開 Xmanager - Passive
[root@db1 bin]# ./jconsole
輸入 192.168.182.5:9999 monitorRole QED 進入
OK
########## 漫談 tomcat 優化與 time-out #########
【tomcat】
啓動一般會所在用戶的環境變量
TIME_WAIT相關sysctl參數及超時時間
[root@lvs ~]# sysctl -a | grep tw
net.ipv4.tcp_max_tw_buckets //處於TIME_WAIT狀態的socket數目的最大值
net.ipv4.tcp_tw_recycle = 1 //打開TIME_WAIT快速回收機制
net.ipv4.tcp_tw_reuse //TIME_WAIT狀態socket複用
Sysctl –w net.ipv4.tcp_tw_len = 2 設置TIME_WAIT在2秒後超時
默認TIME_WAIT超時時間爲60秒,不可通過sysctl調節
如果tomcat本身指定的話:vi bin/setclasspath.sh
JAVA_HOME=/mall/jdk/jdk1.7.0_80
JRE_HOME=/mall/jdk/jdk1.7.0_80/jre
爲httpsession安全性考慮,防止客戶端腳本讀取session cookie內容諸如進行CSRF/XSS惡意http***,可在tomcat6的
conf/context.xml配置文件中配置 <Context useHttpOnly="true"> 爲自定義cookie及屬性添加HttpOnly屬性,在set-Cookie頭部信息設置時可以添加"httponly"
tomcat訪問url不需要加項目名,直接IP+port
<context path="" docBase="/home/tomcat/tomcat8080/webapps/jsjp" reloadable=“true”>
tomcat監控 1、tomcat的應用端口(如8080),比較有侷限性
2、tomcat的jmx監控,是tomcat的性能監控,tomcat的運行情況
3、tomcat可以寫個靜態文件 curl -I URL,獲取報文頭的http返回碼200則爲正常。
---------------------------------------------------------------------------------------
這個配置文件時tomcat7的server.xml 關於線程池
Tomcat最大可能達到的線程數是maxConnections這個參數和併發數
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="3000" minSpareThreads="800"/> maxThreads:Tomcat線程池最多能起的線程數;線程數是pool,用來處理連接數的
maxConnections:Tomcat最多能併發處理的請求(連接);
<Connector executor="tomcatThreadPool" port="8084" protocol="org.apache.coyote.http11.Http11AprProtocol"
connectionTimeout="60000"
keepAliveTimeout="30000" 因爲用了Keep-Alive導致程序性能下降,TPS降低了很多導致的
maxKeepAliveRequests="8000"
maxHttpHeaderSize="8192"
URIEncoding="UTF-8"
enableLookups="false"
acceptCount="1000" acceptCount:Tomcat維護最大的對列數;maxThreads是指Tomcat線程池做多能起的線程數,而 maxConnections 則是Tomcat一瞬間做多能夠處理的併發連接數。
比如maxThreads=1000,maxConnections=800,假設某一瞬間的併發時1000,那麼最終Tomcat的線程數將會是800,即同時處理800個請求,剩餘200進入隊列“排隊”,
如果acceptCount=100,那麼有100個請求會被拒掉。
disableUploadTimeout="true"
redirectPort="8443" />
keepAliveTimeout:長連接最大保持時間(毫秒),表示在下次請求過來之前,Tomcat 保持該連接多久,默認是使用 connectionTimeout 時間,-1 爲不限制超時。
thread dump看其實真正處於RUNNABLE狀態的線程很少,絕大部分線程都處於TIMED_WAITING狀態
netstat -nat|grep 8098 |grep TIME_WAIT |wc -l 2980
netstat -nat|grep 8098 |wc -l 3000 大夥都開始糾結爲什麼線程會漲到3000,而且發現即使峯值過了線程數並不會降下來。
我們首先想到的是:後端應用的處理瞬間比較慢,“堵住了”導致前端線程數漲了起來。但是優化一個版本上線後發現雖然漲的情況有所好轉,但是最終線程池還是會達到3000這個最大值。
直接跟各位說下目前我得到的結論:
1、首先是爲什麼線程不釋放的問題?
簡單說下我驗證的Tomcat(7.0.54)線程池大概的工作機制
Tomcat啓動時如果沒有請求過來,那麼線程數(都是指線程池的)爲0;一旦有請求,Tomcat會初始化minSapreThreads設置的線程數;
Tomcat不會主動對線程池進行收縮,除非確定沒有任何請求的時候,Tomcat纔會將線程池收縮到minSpareThreads設置的大小;
Tomcat6之前的版本有一個maxSpareThreads參數,但是在7中已經移除了, 所以只要前面哪怕只有一個請求,Tomcat也不會釋放多於空閒的線程。至於Tomcat爲什麼移除maxSpareThreads這個參數,我想也是出於性能的考慮,不停的收縮線程池性能肯定不高,而多餘的線程處於等待狀態的好處是一有新請求過來立刻可以處理。
而且大量的Tomcat線程處於等待狀態不會消耗CPU,但是會消耗一些JVM存儲。進一步驗證發現只有使用Keep-Alive(客戶端和服務端都支持)時纔是這種表現,如果客戶端沒有使用Keep-Alive那麼線程會隨着TCP連接的釋放而回收。
注意:根據前面所說,只是併發那一瞬間Tomcat會起800個線程處理請求,但是穩定後,某一瞬間可能只有很少的線程處於RUNNABLE狀態,大部分線程是TIMED_WAITING,如果你的應用處理時間夠快的話。
所以真正決定Tomcat最大可能達到的線程數是maxConnections這個參數和併發數,當併發數超過這個參數則請求會排隊,這時響應的快慢就看你的程序性能了。
Tomcat會停止長時間閒置的線程。 Tomcat還有一個參數叫 maxIdleTime :其實從這個參數解釋也能看出來Tomcat會停止閒置了超過一定時間的線程的,這個時間就是maxIdleTime
添加虛擬內存
JAVA_OPTS="-server -Xms2048m -Xmx4086m -XX:PermSize=256M -XX:MaxNewSize=512m -XX:MaxPermSize=512m -Djava.awt.headless=true"
Xms:jvm初始化堆大小
Xmx:最大java堆大小,超出就會內存溢出
CATALINA_OPTS="
-server
-Xms6000M jvm初始化堆大小
-Xmx6000M 最大java堆大小,超出就會內存溢出
-Xss512k 表示每個 Java 線程堆棧大小,JDK 5.0 以後每個線程堆棧大小爲 1M,以前每個線程堆棧大小爲 256
-XX:NewSize=2250M 設置新生代內存大小。
-XX:MaxNewSize=2250M 設置最大新生代新生代內存大小
-XX:PermSize=128M 設置持久代內存大小
-XX:MaxPermSize=256M 設置最大值持久代內存大小,永久代不屬於堆內存,堆內存只包含新生代和老年代。
-XX:+AggressiveOpts
-XX:+UseBiasedLocking
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:MaxTenuringThreshold=31
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-Duser.timezone=Asia/Shanghai
-Djava.awt.headless=true"
二:現網zabbix使用jvm工具,監控tomcat性能。
1、安裝Zabbix-Java-gateway(忽略)
2、tomcat啓動腳本添加參數,開啓JMX(忽略)
3、zabbix新建監控項-觸發器-圖形
圖形化:
監控項定義,tomcat性能監控項:
堆內存已使用,已提交(與系統tcp監控相輔相成),活動線程總計、峯值
參考博客 http://www.cnblogs.com/Eivll0m/p/5446311.html