tomcat使用jvm性能监控与zabbix使用

vivion32

　　

　　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(这是我的windowsＩＰ，待会儿要开启图形化界面，如果是ｌｉｎｕｘ机器是本机虚拟机，那么IP应该写LINUX的IP的网关 192.168.182.1)
　　打开 Xmanager - Passive
　　[root@db1 bin]# ./jconsole
　　输入  192.168.182.5:9999    monitorRole  QED  进入
　　ＯＫ
　　

　　

##########  漫谈 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配置文件中配置  为自定义cookie及属性添加HttpOnly属性，在set-Cookie头部信息设置时可以添加"httponly"
　　

　　tomcat访问url不需要加项目名，直接IP+port
　　
　　

　　tomcat监控 1、tomcat的应用端口(如8080)，比较有局限性
　　2、tomcat的jmx监控，是tomcat的性能监控，tomcat的运行情况
　　   3、tomcat可以写个静态文件 curl -I URL，获取报文头的http返回码200则为正常。
　　---------------------------------------------------------------------------------------
　　这个配置文件时tomcat7的server.xml 关于线程池
　　

　　Tomcat最大可能达到的线程数是maxConnections这个参数和并发数
　　

　　              maxThreads:Tomcat线程池最多能起的线程数；线程数是pool，用来处理连接数的
　　                                                       maxConnections:Tomcat最多能并发处理的请求（连接）；
　　
　　
　　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新建监控项-触发器-图形
　　https://s1.运维网.com/wyfs02/M00/8F/5F/wKiom1jcZULD5BFUAAC0v6nST10301.png-wh_500x0-wm_3-wmp_4-s_2155337687.png
　　图形化：
　　https://s3.运维网.com/wyfs02/M01/8F/5F/wKiom1jcZgSAaQx7AACR4bT_jno383.png-wh_500x0-wm_3-wmp_4-s_619936372.png
　　

　　

　　监控项定义，tomcat性能监控项：
　　堆内存已使用，已提交(与系统tcp监控相辅相成)，活动线程总计、峰值
　　参考博客 http://www.cnblogs.com/Eivll0m/p/5446311.html