【排故】系统卡顿如何快速定位问题？分享一次排故的过程

1.现象

        公司为应对企业成长所带来了各类公文审批工作，购买了一套办公自动化系统，但是系统在运行过程中会时不时发生系统级别的卡顿，用户访问公文的时候基本上等待数分钟都无任何响应。

2.第一次处理

2.1.分析过程1

        由于业务逻辑，以及部署环境，可能造成卡顿的地方还比较多。首先，我们从请求链路分析，即从：客户端->网络->网关->应用云平台主机->应用运行环境->数据库 等一些系统部署以及网络拓扑图进行分析和测试

2.2.处理过程1

        通过整理出如上的拓扑图，然后逐一检查性能瓶颈，其实这个过程，设计不同部门配合，是比较繁琐，耗时较长的工作，并且不同部门不同人进行操作，从第一轮的排查过程中，我们发现了一些问题，比如数据库慢查询、单次访问请求量较多（且较多时无效的请求）等等问题

2.3.结果1

        一定程度上缓解了压力，但是程序运行一段时间同样的故障又发生了

2.4.复盘1

        由于本次分析，从请求分析，牵扯部门较多，多部门多人员配合，不同人员对系统担任的责任是不同的，有的责任较大，有的责任较小，导致不同人在排故过程的责任心也是不一样的。

3.第二次处理

3.1.分析过程2

        汲取第一次排故过程存在的问题，以及第一次排故过程经验，我们逐步缩小范围，定位在服务器自身或Mysql数据库可能存在问题。本次通过搭建性能监控工具，对应用服务器，以及应用本身进行性能监控，发现是程序代码问题。

3.2.问题处理

        通过监控工具反馈，性能出现问题的时候，即时去应用服务器通过jvisualVM监控JVM运行情况。主要问题：程序逻辑异常生成大量数据，且被加载到内存中，导致内存处于溢出的边缘。主节点，频繁触发JVM的父GC，由于JVM进行父GC导致JVM的STW（stop the world），导致运行非常卡顿，分析原因是由于主节点有大量的定时任务。

        次要问题1：系统安全包设计，需要过滤所有请求，由于安全过滤较严格，安全监测损耗也存在性能损耗较多

        次要问题2：JVM默认机制，JVM在接收请求之后首先要去获取ipv6，若未获取到再去获取ipv4，目前我们环境并没有ipv6，所以我们需要调整jvm参数-Djava.net.preferIPv4Stack=true 直接指定跳转到Ipv4，取消ipv6

3.3 结果

        通过对代码优化，后续监控并未出现之前的卡顿现象，至此才能算终于解决了系统卡顿的问题。

4.整体复盘，JVM性能排故和调优路径

4.1技术上

        1.通过现象进行分析，比如通过浏览器请求，直观进行分析

        2.整理请求访问拓扑图，从每个结点进行排查，避免由于请求中某一个节点存在性能问题导致系统卡顿

        3.分析JVM的dump文件，通过JVM的jvisualvm工具，分析dump文件，是否有频繁父GC，以及是否有大数据加载入JVM内存中

        4.分析程序日志，查看程序运行的慢请求，执行的慢sql

        5.程序逻辑分析，涉及程序内部的拦截器，处理逻辑

        6.分析JVM默认机制

4.2.组织上

        1.达成共识，各方不能推脱责任

        2.组件专项团队，（定时间、空间、人员）

        3.确定时间周期，和沟通机制

4.3.心得

        如果某一个时间点访问系统的所有问题都出现了卡顿，那么有可能出现的问题如下：数据库出现了慢查询导致后续sql排队等待查询，网络出现了拥挤，JDK出现了STW或者处理消息过大