服务器负载过高问题分析-不是cpu高负载也不是IO负载如何处理(阿里 几乎是必考题)

关于top命令 经常问load average 参考：load average 定义(网易面试)

jvm dump的使用 参考：Jvm dump jstack jmap jstat 介绍与使用（内存与线程） 以及使用jstack定位问题

查看端口：如何在Windows,Linux下查看JAVA端口占用情况(阿里)

问题现象：

1，top命令查询服务器负载达到2.0-5之间，tomcat的cpu使用率达到104%

 

 load average: 

linux系统中的Load对当前CPU工作量的度量。简单的说是进程队列的长度。

Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。 

问题分析过程：

1），磁盘使用率未超出正常范围   

df -l

 

2），内存使用率未超出正常范围还有空闲

free

 

 

 

free -m 查看linux系统内存使用量和交换区使用量，如图所示。

 

3），服务器流量未现明显峰值

 

 

4）jvm内存状态未现异常非GC原因

 至于具体的jstat jmap jstack 的使用情况 

参考：Jvm dump jstack jmap jstat 介绍与使用（内存与线程） 以及使用jstack定位问题

综合初步预估是tomcat有线程一直在运行占用cpu资源 

问题引出：如何确定tomcat的100%的cpu使用率到底问题在哪？ 

问题定位方案：

使用java提供的是jstack线程分析命令对进程里面的线程状态进行分析，先导出线程快照再分析具体是那个线程及对应的类 

执行步骤：

第一步：ps -ef|grep tomcat 查询出java/tomcat进程PID（eg:8209）

第二步：ps -aux 查询出该进程是哪个用户启动的（即使ROOT用户可能也导出线程快照失败） 

第三步：su  tomcat 切换到进程启动用户

第四步：jstack -l 8209 > /usr/local/work/tomcat/8209.stack 导出PID对应的线程信息到文件

第五步：对导出的线程文件下载本地做分析（可以文本打开）

第六步：top -H -p 8209 命令查看对应进程是哪个线程占用CPU过高(eg:8308)

 

 第七步：printf "%x\n" 8308 转换十进制为十六进制 此处为：2074

第八步：在导出的堆栈文件中搜索线程ID等于nid=0x2074的线程，此处即列出了该线程对应的类 

 第九步：根据线程信息找到对应的类定位问题成功，找到原因：日志队列线程一直处于RUNNABLE状态，一直在while循环判定队列是否为空

 参考：服务器负载过高问题分析

jstack -m PID (亲自使用-过没问题)

jstack [option] <pid>
说明：
1、option：命令选项，常用选项如下：

（1）-F：当’jstack [-l] pid’没有相应的时候强制打印栈信息,如果直接jstack无响应时，用于强制jstack），一般情况不需要使用

（2）-l长列表： 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表，会使得JVM停顿得长久得多（可能会差很多倍，比如普通的jstack可能几毫秒和一次GC没区别，加了-l 就是近一秒的时间），-l 建议不要用。一般情况不需要使用

（3）-m：打印java和native c/c++框架的所有栈信息.可以打印JVM的堆栈,显示上Native的栈帧，一般应用排查不需要使用

2、pid：进程id
 
原文链接：jstack的使用

 

 使用 iostat -d -x -k 1 10 详解如下： 

iostat -d -k 1 10

查看TPS和吞吐量信息；

参数-d表示，显示设备(磁盘)使用状态；

-k 某些使用block为单位的列强制使用kilobytes为单位；

1 10 表示 数据显示每隔1秒刷新一次，共显示10次；

-x 查看设备使用率(%util),响应时间(await)
一般 %util大于 70%  I/O 压力就比较大，说明产生的I/O请求太多，
I/O系统已经满负荷，该磁盘可能存在瓶颈，

 iotop命令；

我们通过iostat 的常用命令基本可以判断IO是否存在瓶颈了，然后我们
通过iotop命令来抓出罪魁祸首的进程，这里比较简单，直接输入命令；

 

参考：服务器IO高问题定位与优化