【性能测试】java性能问题排查提效脚本工具

本文主要讲述针对cpu高耗和网络IO瓶颈两个场景，使用排查提效脚本工具快速定位分析性能瓶颈

场景一：当服务器CPU高耗原因分析，如何快速定位到占用cpu高的用户线程

1. top命令找出消耗CPU高的Java进程及其线程id：

1. 开启线程显示模式（top -H，或是打开top后按H）
2. 按CPU使用率排序（top缺省是按CPU使用降序，已经合要求；打开top后按P可以显式指定按CPU使用降序）
3. 记下Java进程id及其CPU高的线程id

2. 查看消耗CPU高的线程栈：

1. 用进程id作为参数，jstack出有问题的Java进程
2. 把上述记录的10进制线程id手动转换成十六进制线程id（可以用printf %x 1234）
3. 在jstack输出中查找十六进制的线程id（可以用vim的查找功能/0x1234，或是grep 0x1234 -A 20）

3. 查看对应的线程栈，分析问题

实战案例：

项目部署：jvmpertest + tomcat +jdk1.8

　　　　1、 解压 tomcat的包

　　　　2 、把jvmpertest.war包 放tomcat的webapps

　　　　3、 启动tomcat， 默认端口 8080

　　　　4、 http://serverip:8080/JvmPertest/pertest1 测试接口　　

　　　　5 、http://serverip:8080/JvmPertest/PerThreadTest 创建线程

　　　　6 、jmeter编写脚本

分析方法1：

　　　　1 、使用top命令或者jps命令可以或得进程ID 21767

　　　　2 、但是进程只是资源的拥有者，并不是执行者，所以需要找到进程中的线程，使用命令：top -Hp +进程id可以得到进程中的所有线程

top -Hp 21767

 调用接口：http://serverip:8080/JvmPertest/PerThreadTest，发现，我们top命令中 us态，已经达到100%，执行 top -Hp 进程id 找到了新增的线程的id 23054

要把线程id 转换为16进制， 因为，我们要定位线程的问题，这些线程的栈 信息是在内存中，是16进制显示在内存中，命令：printf"%x\n" +线程id

 输入命令jstack 进程id | grep 线程id的16进制  -A20 从前往后显示20行（jstack 21767 |grep 5a0e  -A20 ） 源代码显示现在，我们这个项目导致CPU的us态很高的原因，是 ThreadPerTest.java文件中的第 15行代码

分析方法2（show-busy-java-threads.sh脚本排查）：

1、wget --no-check-certificate https://github.com/oldratlee/useful-scripts/archive/release.zip下载
2、unzip release.zip
3、sh show-busy-java-threads.sh 从所有运行的Java进程中找出最消耗CPU的线程（缺省5个），打印出其线程栈（同排除思路）
4、也可以指定进程：show-busy-java-threads -p <指定的Java进程Id>

用法解析：

show-busy-java-threads -p <指定的Java进程Id>

show-busy-java-threads -c <要显示的线程栈数>

show-busy-java-threads <重复执行的间隔秒数> [<重复执行的次数>]

# 多次执行；这2个参数的使用方式类似vmstat命令

show-busy-java-threads -a <运行输出的记录到的文件># 记录到文件以方便回溯查看

show-busy-java-threads -S <存储jstack输出文件的目录># 指定jstack输出文件的存储目录，方便记录以后续分析

 

场景二：怀疑网络连接问题，如何快速分析网络TCP状态

tcp-connection-state-counter脚本，统计各个TCP连接状态的个数。

支持Linux、Mac、Windows（cygwin、MSSYS）。

像Nginx、Apache的机器上需要查看，TCP连接的个数，以判定

连接数、负荷
是否有攻击，查看SYN_RECV数（SYN攻击）
TIME_WAIT数，太多会导致TCP: time wait bucket table overflow。

 示例：

 参考文档：

https://www.cnblogs.com/johnny-chen/p/13359826.html

https://www.cnblogs.com/hailangboke/p/16368945.html#5201810

https://blog.csdn.net/ya_shy/article/details/126073768