问题现象工作中遇到一个并发现象我们的自动化测试平台包含任务列表、脚本管理、远程真机、用户管理和机柜大屏等多个功能模块。随着今年用户量激增服务器压力明显增大导致页面响应出现卡顿现象虽然不影响核心功能执行。特别值得注意的是当打开机柜大屏时系统会在2分钟内出现严重卡顿直接影响平台脚本列表的查询功能。分析过程1、页面分析首先打开页面通过控制台F12将时间倒叙排序观察页面接口调用直至卡顿出现。观察后发现随着大屏监控的开启某一个接口耗时逐步增加从100ms到1s再到10s且数量越来越多。2、kube分析注意这步的排查思路跑偏了写在文档里只是提供一种拓展的思路以及对kube观察的理解。我们观察了脚本所在服务、任务所在服务、设备所在服务的pod,以及es、mongodb、mysql、redis等数据库资源。在这块走了不少弯路甚至排查方向一度出现问题。由于测试环境无法重现生产环境的并发问题我们使用JMeter对卡顿接口脚本列表和任务列表进行了压力测试直到页面出现卡顿直至崩溃的现象。随后排查MySQL慢SQL时发现虽然存在慢查询但并未出现大量积压的SQL请求因此排除了这个主要原因。不过通过这次排查我们也发现了一些平台需要优化的地方比如脚本列表查询和任务查询等慢SQL问题。以下是详细的排查过程1、使用jemeter压测工具将脚本列表查询接口的并发线程数提升至100后页面在1分钟内即出现明显卡顿现象。2、观察pod资源我们观察到user-e服务的CPU 2939%CPU/R 146说明CPU 已经超出 request 很多了 已远超申请配额。同时filesystem 服务也存在类似情况。经分析 pod 运行状态后我们决定优先排查 user-e 服务 pod 中的线程竞争和锁冲突等并发问题。3、进入pod中查询jvm问题首先输入jps -l查询进程 ID输出为 6然后输入jstat -gcutil 6 1000命令每秒钟输出一次 GC 状态。观察到 FGC垃圾回收次数始终保持在 2 且没有异常增长说明 JVM 内存运行正常。因此将排查重点转向线程阻塞和数据库问题。4、查询线程阻塞情况执行命令top -Hp 6其中6为进程IDThreads: 68 total 5 running 63 sleeping说明线程数并不高这很重要因为如果是线程池爆炸、请求堆积或连接池耗尽你通常会看到几百上千个线程但你这里只有68个线程说明不是线程数量失控。此处CPU结构也很关键数据显示63%CPU空闲这意味着并不是 CPU 真被打满了27.3 us 63.0 id指标含义us用户态CPUidCPU空闲分析到这思路已经偏离很远了但排查JVM和线程状态对单个服务的问题定位仍有必要。然而当前涉及多个前后端服务这种单一维度的排查方案存在局限性。即便后续排查了MySQL慢查询等问题仍未找到根本原因此处不再详述。接下来我们将引入Arthas监控诊断工具结合页面分析结果通过该工具辅助定位问题根源最终解决问题。3、Arthas分析Arthas诊断工具可以通过全局视角实时查看应用 load、内存、gc、线程的状态信息并能在不修改应用代码的情况下对业务问题进行诊断包括查看方法调用的出入参、异常监测方法执行耗时类加载信息等大大提升线上问题排查效率。https://arthas.aliyun.com/doc/quick-start.html1、下载Arthas至服务器由于我们是内网系统开发所以是从官网下载导入到服务器的如果你所在的服务可联网可以直接通过官网提供的命令行安装。2、启动Arthas解压后使用java -jar arthas-boot.jar命令启动3、trace查询追踪调用链路获取1-页面分析中卡顿接口在代码中的路径使用trace命令查询链路耗时一步一步查询卡顿所在trace --skipJDKMethod false cn.testin.service.report.Report listDeviceReport #cost 200通过上图分析可以看出具体方法及各步骤的耗时情况其中某一步骤调用频繁且耗时较高。经代码排查发现该步骤调用次数过多占据了程序大部分执行时间导致其他接口调用被迫等待从而引发页面卡顿。后将此处代码优化后页面卡顿现象得到解决。