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、*Error
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没写好导致慢查询,可能会导致整个应用挂起

此时需要查看数据库连接请求、是否连接数过大,是否出现死锁、查看数据库慢日志定位具体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

参考连接:

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
上一篇:四步搞定ansible-tower


下一篇:50个最常用的Linux命令