〇、一件事儿
以下分析是站在Java工程师的角度来分析的。
一、CPU分析
分析CPU的繁忙程度，两个指标：系统负载和CPU利用率
1、系统负载分析
系统负载：在Linux系统中表示，一段时间内正在执行进程数和CPU运行队列中就绪等待进程数，以及非常重要的休眠但不可中断的进程数的平均值（具体load值的计算方式，有兴趣可以自行深究，这里不深究）。说白了就是，系统负载与R(Linux系统之进程状态)和D(Linux系统之进程状态)状态的进程有关，这两个状态的进程越多，负载越高。
查看系统负载，见top命令：第1部分。
怎么看load average的值？
通常先看15分钟的load值，如果load很高，再看1分钟和5分钟的load值，查看是否有下降趋势。短时间内load值高，无须太担心；但是如果长时间内load值持续过高，那么就要赶紧看看发生了什么。- 需要警惕的load average的值（以单核CPU为例）:
- load值持续大于0.7，必须开始找问题出在哪里，防止情况恶化；
- load值持续大于1.0，解决问题已迫在眉睫；
load值持续大升高达到5.0，表示各种请求几乎得不到响应，机器几近崩溃；
对于多核机器，则需要根据CPU个数来判断系统负载是否过高。如，若认为0.7算是单核机器负载的安全线的话，则四核机器的负载最好保持在3(4*0.7 = 2.8)以下。
- load值持续大于0.7，必须开始找问题出在哪里，防止情况恶化；
2、CPU利用率分析
- 看CPU的空闲率，用户进程CPU使用率和系统进程CPU使用率。
- 看个别进程的CPU利用率是否明显高于其他进程：
- 死循环？
- 复杂计算？
- 超大对象耗时读写？
查看CPU利用率，见top命令：第3部分和第5部分。
3、综合两个分析
- CPU利用率高，系统负载低
- 死循环？
- 复杂计算？
- 超大对象耗时读写？
- 系统负载高，CPU利用率低
- 大量IO操作？
- 大量死锁？
- 大量执行耗时SQL？
- 内存不足，频繁GC？
- 系统负载高，CPU利用率高
- 大量进程出现死循环？
- 大量进程进行复杂计算？
- 大量进程对超大对象耗时读写？
- 硬件无法支撑应用，升级机器？
三、内存分析
- 看总内存的使用情况；
- 是否有个别进程内存消耗明显高？
- JVM内存设置是否合理？
- 是否有大对象长时间未释放？
查看内存使用情况，见free命令和top命令：第5部分。
四、I/O分析
- 如果avgqu-sz比较大，表示相当量的io在等待；
- 如果svctm比较接近await，说明I/O几乎没有等待时间；如果 await远大于svctm，说明I/O 队列太长，io响应太慢，则需要进行必要优化；
- 如果%util接近 100%(70%为安全线)，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈；
- 如果I/O存在瓶颈，可以用pidstat命令找到I/O读写高的进程；
查看I/O读写状况，见iostat命令。
五、网络分析
netstat分析：
- 分析连接状态
- 若服务端出现了大量TIME_WAIT状态的连接，说明该服务器经常主动发起连接关闭操作，这是不可取的；
- 若一个系统频繁出现CLOSE_WAIT状态的连接，说明该系统并未立即处理连接关闭请求，系统存在缺陷；
- 分析网络队列
- 若Recv-Q过大，说明系统未能及时处理外部发来的请求；
若Send-Q过大，说明系统发包速度过快以至于连接无法及时将数据发出，或者对端接收数据包慢
这两个值通常应该为0，如果不为0可能是有问题的；数据包在两个队列里都不应该有堆积；可接受短暂的非0情况。
分析服务器端能否正常处理客户端连接
如果Recv-Q队列大小值>=设置的somaxconn值（cat /proc/sys/net/core/somaxconn）说明服务器无法适应当前连接建立速度，不能及时accept新的连接。客户端在调用listen时，会传递backlog参数，该参数为“已建立连接但未被程序accept的连接队列的长度”，内核层会根据cat /proc/sys/net/core/somaxconn值与传入的backlog值，选择两者中的小值作为“已建立连接但未被服务器accept的连接队列长度”
tcpdump分析：
tcpdump通过抓指定端口的数据包，可以分析指定进程的数据包流量。
通过抓包工具tcpdump及网络状态查看命令netstat可以帮助定位客户端、服务端相关网络问题，在日志匮乏或性能统计信息不足以分析服务器问题时，可以辅助分析服务器相关模块性能。
查看网络连接状况，见netstat命令和tcpdump命令。
六、排查思路
- 系统负载、CPU利用率、内存、I/O、网络等因素综合考虑，才是解决问题的关键。
- 先整体分析哪块问题，再定位特征进程（例如CPU利用率明显高于其他进程的进程），进而结合jstack定位到线程和代码。
