Tomcat假死排查方案

  使用Tomcat做为Web服务器的时候偶尔会遇到Tomcat中止响应的状况,经过netstat查看端口状况会发现tomcat的端口出现大量的CLOSE_WAIT,此时Tomcat会中止响应前端请求,同时服务端的日志,操做等将所有中止,并且没有出现任何异常,此时就须要排查是哪方面的缘由,此案以之前的解决为例总结排查方案前端

  

  一、首先确认页面端正常时请求没有问题数据库

  二、对于使用Nginx做为前端负载均衡Tomcat集群,经过Nginx的访问日志(access.log)确认页面到Nginx没有问题tomcat

  三、查看Tomcat的访问日志(localhost_access_log.txt)查看前端请求是否访问到Tomcat服务器

    

 

  四、查看Tomcat的状态控制台,查看Tomcat的请求和内存占用状况负载均衡

    

    查看那些请求处于等待状态,排查这些请求的服务是否存在问题(长事务、频繁事务)框架

  五、查看数据库进程查看当前数据库实例是否出现死锁日志

    

    若是出现死锁,排查代码中出现死锁的缘由,解决死锁问题blog

  六、若是以上都没有问题,排查代码中的定时任务进程

    查看定时任务事务是否存在问题(长事务、频繁事务)事务

  七、检查是不是频繁的写日志形成Tomcat阻塞

    对于访问量比较大的系统,若是项目采用Info或者Debug日志级别的话会形成Tomcat频繁的读写几百兆甚至上G的日志文件,形成Tomcat阻塞

 

曾经遇到的一次Tomcat出现CLOSE_WAIT时,经过排查发现是一位同事在经过定时任务作其余系统的数据同步时时出现的问题形成的,问题总结以下:  一、同步其余系统的数据是耗时较长,其采用Spring的切面事务,形成同步时事务时间长达几分钟时间,存在死锁风险  二、同步数据完须要处理数据,此时的处理数据逻辑会存在多达几万次的数据库变动,当前操做没有采用切面事务,而是采用框架的AutoCommit自动提交事务,这样就会形成处理数据时出现几万次的建立事务,提交事务,关闭事务,此时形成事务阻塞解决方案:  一、处理时间较长的操做,若是当前操做中间出现问题对业务没有影响下次操做时会修正当前业务,这样的话能够不适用切面事务而是使用框架的AutoCommit提交事务,若是当前操做确实须要保证原子性时,请手动回复数据装填  二、不要频繁的开启、提交事务,采用批量的方式提交事务

相关文章
相关标签/搜索