java线上服务问题排查总结
java线上服务问题排查
1、业务日志相关
如果应用系统出现异常,一般都会在业务日志中体现 统计当天业务日志中ERROR出现数量:egrep ERROR --color logname | wc -l ,如果错误数量过大,一般都是有问题的 查看日志中ERROR后10行具体报错:egrep -A 10 ERROR logname | less ,或 -C 10 查看ERROR前后10行日志
- Java中,所有异常都继承自Throwable类(一个完整可用的类)。整体上分为Error、Exception两个大类,Exception大类又分为UncheckedException(继承于RuntimeException)和CheckedException(继承于Exception,但不继承于RuntimeException)。
常见异常关键字有:ERROR、Exception
ERROR:AssertionError、OutOfMemoryError、StackOverflowError UncheckedException:AlreadyBoundException、ClassCastException、ConcurrentModificationException、IllegalArgumentException、IllegalStateException、IndexOutOfBoundsException、JSONException、NullPointerException、SecurityException、UnsupportedOperationException CheckedException:ClassNotFoundException、CloneNotSupportedException、FileAlreadyExistsException、FileNotFoundException、InterruptedException、IOException、SQLException、TimeoutException、UnknownHostException # 上述参考:http://www.importnew.com/27348.html
- 以时间段查看日志、先查看日志的时间格式,使用sed命令截取特定时间段日志,在过滤异常关键字,如下:
sed -n '/起始时间/,/结束时间/p' 日志文件 sed -n '/2018-12-06 00:00:00/,/2018-12-06 00:03:00/p' logname # 查询三分钟内的日志,后再跟grep 过滤相应关键字 sed -n '/2018-12-06 08:38:00/,$p' logname | less # 查询指定时间到当前日志 # ps:禁止使用vim直接打开日志文件
2、数据库相关
Java应用非常多瓶颈在数据库,一条sql没写好导致慢查询,可能会导致整个应用挂起
- 关注日志中出现的Could not get JDBC Connection,JDBCException
- 参考:http://docs.jboss.org/hibernate/orm/3.2/api/org/hibernate/JDBCException.html
此时需要查看数据库连接请求、是否连接数过大,是否出现死锁、查看数据库慢日志定位具体SQL
3、JVM相关
Java虚拟机相关的问题一般多是下面几种问题:gc时间过长、OOM、死锁、线程block、线程数暴涨等问题。一般通过下面几个工具都能定位出问题。
- 常用的JDK监控和故障处理工具:jps, jstack, jmap、jstat, jconsole, jinfo, jhat, javap, btrace、TProfiler
名称 主要作用 jps JVM Process Status Tool,用来查看基于HotSpot的JVM里面中,所有具有访问权限的Java进程的具体状态, 包括进程ID,进程启动的路径及启动参数等等,与unix上的ps类似,只不过jps是用来显示java进程,可以把jps理解为ps的一个子集。 jstat JVM Statistics Monitoring Tool,jstat是用于监视虚拟各种运行状态信息的命令行工具,它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。 jinfo Configuration info for java,命令的作用是实时的查看和调整虚拟机的参数。 jmap Memory Map for java,生成虚拟机的内存转储快照(heapdump) jhat JVM Heap Dump Browser,用于分析heapdump文件,它会建立一个Http/HTML服务器,让用户可以在浏览器上查看分析结果 jstack Stack Trace for java,显示虚拟机的线程快照。 使用--help,查看命令具体使用 常用: jps -v jstat -gc 118694 500 5 jmap -dump:live,format=b,file=dump.hprof 29170 jmap -heap 29170 jmap -histo:live 29170 | more jmap -permstat 29170 jstack -l 29170 |more
参考连接:
- JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解:https://blog.csdn.net/wisgood/article/details/25343845
- JVM的常用性能监控工具jps、jstat、jinfo、jmap、jhat、jstack:https://blog.csdn.net/u010316188/article/details/80215884
- JVM系列五:JVM监测&工具[整理中]:https://www.cnblogs.com/redcreen/archive/2011/05/09/2040977.html
- jvm系列五:监测命令(jvisualvm jps jstat jmap jhat jstack jinfo)及dump堆内存快照分析:https://blog.csdn.net/xybelieve1990/article/details/53516437
- JVM学习之jstat使用方法:https://www.cnblogs.com/parryyang/p/5772484.html
- jstat命令查看jvm的GC情况 (以Linux为例):https://www.cnblogs.com/yjd_hycf_space/p/7755633.html
- java进程CPU过高排查:https://www.cnblogs.com/Dhouse/p/7839810.html
- https://stackify.com/java-performance-tools-8-types-tools-need-know/
- https://stackoverflow.com/questions/97599/static-analysis-tool-recommendation-for-java
3.1、OOM相关
发生OOM问题一般服务都会crash,业务日志会有OutOfMemoryError。
- OOM一般都是出现了内存泄露,须要查看OOM时候的jvm堆的快照,假设配置了-XX:+HeapDumpOnOutOfMemoryError, 在发生OOM的时候会在-XX:HeapDumpPath生成堆的dump文件。结合MAT,能够对dump文件进行分析。查找出发生OOM的原因.
- 关于MAT使用不详述了,google上一堆(http://inter12.iteye.com/blog/1407492)。
ps: 1、server的内存一般较大,所以要保证server的磁盘空间大于内存大小 2、另外手动dump堆快照。能够使用命令jmap -dump:format=b,file=file_name pid 或者kill -3 pid
3.2、死锁
死锁原因是两个或者多个线程相互等待资源。现象通常是出现线程hung住。更严重会出现线程数暴涨,系统出现api alive报警等。查看死锁最好的方法就是分析当时的线程栈。
# 详细case 能够參考jstack命令里面的样例 用到的命令: jps -v jstack -l pid
3.3、线程block、线程数暴涨
jstack -l pid |wc -l jstack -l pid |grep "BLOCKED"|wc -l jstack -l pid |grep "Waiting on condition"|wc -l 线程block问题通常是等待io、等待网络、等待监视器锁等造成,可能会导致请求超时、造成造成线程数暴涨导致系统502等。 假设出现这样的问题,主要是关注jstack 出来的BLOCKED、Waiting on condition、Waiting on monitor entry等状态信息。 假设大量线程在“waiting for monitor entry”:可能是一个全局锁堵塞住了大量线程。 假设短时间内打印的 thread dump 文件反映。随着时间流逝。waiting for monitor entry 的线程越来越多,没有降低的趋势,可能意味着某些线程在临界区里呆的时间太长了,以至于越来越多新线程迟迟无法进入临界区。 假设大量线程在“waiting on condition”:可能是它们又跑去获取第三方资源,迟迟获取不到Response,导致大量线程进入等待状态。 假设发现有大量的线程都处在 Wait on condition,从线程堆栈看,正等待网络读写,这可能是一个网络瓶颈的征兆,由于网络堵塞导致线程无法运行。
3.4、gc时间过长
4、Server本身问题
- 排查:CPU、Memory、IO、Network
- 常用命令:top/htop 、free、iostat/iotop、netstat/ss
关注网络连接: 查看tcp各个状态数量:netstat -an | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 查看连接某服务端口最多的IP:netstat -na | grep 172.16.70.60:1111 | awk '{print $5}' | cut -d : -f1 | sort | uniq -c | sort -rn | head -10
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
开源程序的网站漏洞检测对获取管理员密码漏洞如何修复
PbootCMS是网站常用的一款CMS系统,是由国内著名程序开发商翔云科技研发的一套网站CMS系统,免费开源,扩展性较高,使用的企业很多但是避免不了网站存在漏洞,SINE安全对其代码进行安全审计的同时发现该pbootcms 存在严重的漏洞,包含SQL注入获取管理员密码漏洞,以及远程代码注入执行漏洞。该pbootcms系统采用的是PHP语言开发,数据库是MYSQL,并支持pgsql数据库大并发处理,系统默认支持的服务器环境,PHP5.3版本以上,以及mysql版本5.6,apache,nginx,都可以运行该CMS系统。关于这次检测出来的CMS漏洞,我们进行详细的介绍。 之前的pbootcms老版本出现的漏洞也比较多,我们这次审计的是pbootcms V1.3.3新版本,新版本较于老版本更新了许多,SQL注入非法参数的过滤,以及上传漏洞的修复,过滤系统的加强,但还是始终没有严格的杜绝非法参数的传入。我们来看下这个远程代码注入执行漏洞,该漏洞产生的原因是在ParserController.php代码里的LABEL方式调用shat函数,我们来看下代码: 我们找到label调用的方式,一步步跟...
- 下一篇
java B2B2C Springcloud电子商城系统--------负载均衡(Load Balance)
负载均衡(Load Balance) 由于目前现有网络的各个核心部分随着业务量的提高,访问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,使得单一的服务器设备根本无法承担。在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务量的提升时,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越的设备也不能满足当前业务量增长的需求。愿意了解源码的朋友直接求求交流分享技术:二一四七七七五六三三 负载均衡实现方式分类 1:软件负载均衡技术 该技术适用于一些中小型网站系统,可以满足一般的均衡负载需求。软件负载均衡技术是在一个或多个交互的网络系统中的多台服务器上安装一个或多个相应的负载均衡软件来实现的一种均衡负载技术。软件可以很方便的安装在服务器上,并且实现一定的均衡负载功能。软件负载均衡技术配置简单、操作也方便,最重要的是成本很低。 2:硬件负载均衡技术 由于硬件负载均衡技术需要额外的增加负载均衡器,成本比较高,所以适用于流量高的大型网站系统。不过在现在较有规模的企业网、政府网站,一般来说都会部署有硬件负载均衡设备(原因1.硬件设备更稳定,2...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Linux系统CentOS6、CentOS7手动修改IP地址
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装