java线上服务问题排查
1、业务日志相关
假设系统出现异常或者业务有异常,首先想到的都是查看业务日志
查看日志工具:
less 或者more
grep
tail -f filename 查看实时的最新内容
ps:切忌vim直接打开大日志文件,由于会直接载入到内存的
2、数据库相关
java应用非常多瓶颈在数据库,一条sql没写好导致慢查询,可能就会带来应用带来致命危害。
假设出现Could not get JDBC Connection 、接口响应慢、线程打满等。
须要登录线上库,
查看数据库连接情况:show processlist。查看当前数据库的连接情况。确实因为慢查询造成。须要手动kill
3、JVM相关
java虚拟机相关的问题一般多是下面几种问题:gc时间过长、OOM、死锁、线程block、线程数暴涨等问题。一般通过下面几个工具都能定位出问题。
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.3 gc时间过长
todo
先贴一个文章占坑:http://www.oracle.com/technetwork/cn/articles/java/g1gc-1984535-zhs.html
4、server问题
4.1 CPU
top命令(參考https://linux.cn/article-2352-1.html)
主要关注cpu的load,以及比較耗cpu的进程
因为如今server都是虚拟机,还要关注st(st 的全称是 Steal Time 。是分配给执行在其他虚拟机上的任务的实际 CPU 时间)

经常使用交互命令:
h 帮助。十分实用
R: 反向排序
x:将排序字段高亮显示(纵列)
y 将执行进程高亮显示(横行)
shift+> 或shift+<:切换排序字段
d或s: 设置显示的刷新间隔
f: 字段管理 设置显示的字段
k:kill进程
4.2 内存
free命令:
free -m -c10 -s1
-m:以MB为单位显示。其它的有-k -g -b
-s: 间隔多少秒持续观察内存使用状况
-c:观察多少次
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
vmstat命令:(http://man.linuxde.net/vmstat)
vmstat 1 10
1表示每隔1s输出一次,10 表示输出10次
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
两个參数须要关注
r: 执行队列中进程数量,这个值也能够推断是否须要添加CPU。
(长期大于1)
b: 等待IO的进程数量。
4.3 IO
iostat 命令(http://www.orczhou.com/index.php/2010/03/iostat-detail/)
iostat -m 1 10
- -m:某些使用block为单位的列强制使用MB为单位
- 1 10:数据显示每隔1秒刷新一次。共显示10次

4.4 网络
netstat 命令(http://www.cnblogs.com/ggjucheng/archive/2012/01/08/2316661.html)
netstat -antp
-a (all)显示全部选项。默认不显示LISTEN相关
-t (tcp)仅显示tcp相关选项
-u (udp)仅显示udp相关选项
-n 拒绝显示别名,能显示数字的所有转化成数字。
-l 仅列出有在 Listen (监听) 的服服务状态
-p 显示建立相关链接的程序名

显示tcp各个状态数量:
netstat -ant |awk '{print $6}'|sort|uniq -c
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
查看连接某服务port最多的的IP地址
netstat -nat | grep "10.32.45.35:8924" |awk '{print $5}'|awk -F: '{print $4}'|sort|uniq -c|sort -nr|head -10
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
1、业务日志相关
假设系统出现异常或者业务有异常,首先想到的都是查看业务日志
查看日志工具:
less 或者more
grep
tail -f filename 查看实时的最新内容
ps:切忌vim直接打开大日志文件,由于会直接载入到内存的
2、数据库相关
java应用非常多瓶颈在数据库,一条sql没写好导致慢查询,可能就会带来应用带来致命危害。
假设出现Could not get JDBC Connection 、接口响应慢、线程打满等。
须要登录线上库,
查看数据库连接情况:show processlist。查看当前数据库的连接情况。确实因为慢查询造成。须要手动kill
3、JVM相关
java虚拟机相关的问题一般多是下面几种问题:gc时间过长、OOM、死锁、线程block、线程数暴涨等问题。一般通过下面几个工具都能定位出问题。
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等状态信息。
3.3 gc时间过长
todo
先贴一个文章占坑:http://www.oracle.com/technetwork/cn/articles/java/g1gc-1984535-zhs.html
4、server问题
4.1 CPU
top命令(參考https://linux.cn/article-2352-1.html)
主要关注cpu的load,以及比較耗cpu的进程
因为如今server都是虚拟机,还要关注st(st 的全称是 Steal Time 。是分配给执行在其他虚拟机上的任务的实际 CPU 时间)
经常使用交互命令:
h 帮助。十分实用
R: 反向排序
x:将排序字段高亮显示(纵列)
y 将执行进程高亮显示(横行)
shift+> 或shift+<:切换排序字段
d或s: 设置显示的刷新间隔
f: 字段管理 设置显示的字段
k:kill进程
4.2 内存
free命令:
free -m -c10 -s1
-m:以MB为单位显示。其它的有-k -g -b
-s: 间隔多少秒持续观察内存使用状况
-c:观察多少次
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
vmstat命令:(http://man.linuxde.net/vmstat)
vmstat 1 10
1表示每隔1s输出一次,10 表示输出10次
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
两个參数须要关注
r: 执行队列中进程数量,这个值也能够推断是否须要添加CPU。
(长期大于1)
b: 等待IO的进程数量。
4.3 IO
iostat 命令(http://www.orczhou.com/index.php/2010/03/iostat-detail/)
iostat -m 1 10
- -m:某些使用block为单位的列强制使用MB为单位
- 1 10:数据显示每隔1秒刷新一次。共显示10次
4.4 网络
netstat 命令(http://www.cnblogs.com/ggjucheng/archive/2012/01/08/2316661.html)
netstat -antp
-a (all)显示全部选项。默认不显示LISTEN相关
-t (tcp)仅显示tcp相关选项
-u (udp)仅显示udp相关选项
-n 拒绝显示别名,能显示数字的所有转化成数字。
-l 仅列出有在 Listen (监听) 的服服务状态
-p 显示建立相关链接的程序名
显示tcp各个状态数量:
netstat -ant |awk '{print $6}'|sort|uniq -c
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
查看连接某服务port最多的的IP地址
netstat -nat | grep "10.32.45.35:8924" |awk '{print $5}'|awk -F: '{print $4}'|sort|uniq -c|sort -nr|head -10
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
java线上服务问题排查的更多相关文章
- Java线上应用故障排查之二:高内存占用
搞Java开发的,经常会碰到下面两种异常: 1.java.lang.OutOfMemoryError: PermGen space 2.java.lang.OutOfMemoryError: Java ...
- java线上应用故障排查之二:高内存占用【转】
前一篇介绍了线上应用故障排查之一:高CPU占用,这篇主要分析高内存占用故障的排查. 搞Java开发的,经常会碰到下面两种异常: 1.java.lang.OutOfMemoryError: PermGe ...
- 排查Java线上服务故障的方法和实例分析
前言 作为在线系统负责人或者是一个技术专家,你可能刚刚接手一个项目就需要处理紧急故障,或者被要求帮忙处理一些紧急的故障,这个时候的情景是: (1)你可能对这个业务仅仅是听说过,而不怎么真正了解: (2 ...
- Java线上应用故障排查
线上故障主要2种: CPU利用率很高, 内存占用率很大 一.CPU利用率很高 1. top查询那个进程CPU使用率高 2. 显示进程列表 ps -mp pid -o THREAD,tid,time 找 ...
- java线上应用问题排查方法和工具
linux性能监测点 CPU, Memory, IO, Network Linux性能监测工具-cpu 基本概念: 上下文切换(Context Switches): 如果可运行的线程数大于CPU的数量 ...
- Java线上应用故障排查之一:高CPU占用
一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环. 以我们最近出现的一个实际故障为例,介绍怎么定位和解决这类问题. 根据top命令,发现PID为28555的Java进程占 ...
- Java线上应用故障排查之一:高CPU占用 (转)
一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环. (友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hank ...
- Java线上应用故障排查之一:高CPU占用【转】
近期java应用,CPU使用率一直很高,经常达到100%,通过以下步骤完美解决,分享一下. 方法一: 转载:http://www.linuxhot.com/java-cpu-used-high.htm ...
- Linux(2)---记录一次线上服务 CPU 100%的排查过程
Linux(2)---记录一次线上服务 CPU 100%的排查过程 当时产生CPU飙升接近100%的原因是因为项目中的websocket时时断开又重连导致CPU飙升接近100% .如何排查的呢 是通过 ...
随机推荐
- 二分搜索之C++实现
二分搜索之C++实现 一.源代码:BinarySearch.cpp #include<iostream> using namespace std; /*定义输出一维数组的函数*/ void ...
- SPOJ6717 Two Paths 树形dp
首先有朴素的\(O(n^2)\)想法 首先枚举断边,之后对于断边之后的两棵子树求出直径 考虑优化这个朴素的想法 考虑换根\(dp\) 具体而言,首先求出\(f[i], fs[i]\)表示\(i\)号点 ...
- [BZOJ3507][CQOI2014]通配符匹配(DP+Hash)
显然f[i][j]表示S匹配到第i个通配符,T匹配到第j个字符,是否可行. 一次一起转移两个通配符之间的所有字符,Hash判断. 稍微有点细节.常数极大卡时过排名倒数,可能是没自然溢出的原因. #in ...
- POJ2104 K-th Number 不带修改的主席树 线段树
http://poj.org/problem?id=2104 给定一个序列,求区间第k小 通过构建可持久化的点,得到线段树左儿子和右儿子的前缀和(前缀是这个序列从左到右意义上的),然后是一个二分的ge ...
- BZOJ 1174 [Balkan2007]Toponyms(Trie)
[题目链接] http://www.lydsy.com/JudgeOnline/problem.php?id=1174 [题目大意] 选出一些字符串,使得字符串的最长公共前缀*字符串的总个数最大化 [ ...
- linux中的文件编码及编码修改
查看文件编码 在Linux中查看文件编码可以通过以下几种方式: 1.在Vim中可以直接查看文件编码 :set fileencoding 即可显示文件编码格式. 如果你只是想查看其它编码格式的文件或者想 ...
- hdu 4540 dp
题意: 假设: 1.每一个时刻我们只能打一只地鼠,并且打完以后该时刻出现的所有地鼠都会立刻消失: 2.老鼠出现的位置在一条直线上,如果上一个时刻我们在x1位置打地鼠,下一个时刻我们在x2位置打地鼠,那 ...
- Codeforces Round #296 (Div. 1) A. Glass Carving Set的妙用
A. Glass Carving time limit per test 2 seconds memory limit per test 256 megabytes input standard in ...
- macbook pro 开发帮助
java安装目录 /Library/java/JavaVirtualMachines/ 设置快捷目录 vim .bash_profile 文件中追加一下信息:export dirname=目录路径 重 ...
- Git_git的诞生
很多人都知道,Linus在1991年创建了开源的Linux,从此,Linux系统不断发展,已经成为最大的服务器系统软件了. Linus虽然创建了Linux,但Linux的壮大是靠全世界热心的志愿者参与 ...