苍穹定制化开发性能优化指南系列（三）-浅谈苍穹性能问题排查思路

浅谈苍穹性能问题排查思路

1 前言

在日常使用苍穹或开发的过程中，有时候会遇到系统整体卡顿，数据列表加载缓慢等问题，也有些情况仅是局部出现卡顿，如某个单据打开慢、点击按钮操作慢等，还有线上出现异常问题，但是在开发环境没法复现，又没法调试等等，诸如此类的生产环境问题我们应该如何排查分析呢？这篇指南就来讲解在苍穹生产环境应该如何定位分析上述所提及的种种问题，帮助大家后续在使用或开发苍穹中遇到此类问题时，有一个较清晰的思路更好的去分析解决。

2 整体思路

在系统遇到性能问题时，我们应该有一个大体的思路去思考和定位，大概可以从以下几个方面去考虑：

（1）客户端问题，先排查是不是客户端设备的问题或者是网络问题，特别是在系统整体卡顿的情况下；

（2）前端问题：查看前端和后端耗时的占比，后台接口返回的时间和前端渲染的时间，通过浏览器F12 的network 页签即可查看。目前针对二开而言，大多是后台插件的开发，所以前端的问题暂时可以忽略（不排除有）；

（3）服务器硬件问题：服务器/数据库服务器的物理内存、CPU，资源是否足以支撑系统数据量的运行和存储；

（4）配置问题：

• 中间件参数配置，如nginx 最大连接数，合理的负载均衡策略，redis 最大连接数，最大空闲连接数等；

• 容器内存配置，jvm 参数配置如最大堆内存，gc 方式等；

（5）代码设计问题：是否存在循环取数，锁的处理，并发的处理，线程池的数量等；

3 Monitor 平台简介

在定位分析生产环境问题时，各种指标监控数据、日志等是我们强有力的武器，有助于我们更好的定位问题。我们知道，苍穹是分布式部署的架构，不同的服务模块部署在不同的服务器上，无法像之前单体架构一样直接在服务器上可以快速的查找对应的日志，需要使用集中式日志系统定位问题，一般一个完整的集中式日志系统包含收集（能够采集多种来源的日志数据），传输（能够稳定的把日志数据传输到中央系统），存储（存储日志数据），分析（可以支持UI 分析），警告（能够提供错误报告，监控机制）等主要特点。目前主流的日志系统是ELK，即Elasticsearch（搜集、分析、存储数据三大功能） , Logstash（日志的搜集、分析、过滤）, Kibana（提供的日志分析友好的Web 界面，汇总、分析和搜索重要数据日志） ，它们都是开源软件，提供了一整套解决方案。

在苍穹中，分析日志等也是采用这样的集中式日志系统，Monitor 平台提供了日志查询、系统监控（cpu、内存、线程堆栈等）、调用链查看等功能，如下图所示，Monitor 平台的架构也是与ELK 类似的，只是目前提供日志分析的web界面是Monitor。

日志收集框架简析：

如下图所示，各微服务节点产生的应用日志和性能埋点trace 传递给kafka消息队列中，Logstash 和Zipkin 负责消费kafka 中的消息，经过分析、过滤后发送给远端服务器上的Elasticsearch 进行存储，Elasticsearch 将数据以分片的形式压缩存储并提供多种API 供用户查询，操作。

下面我们将讲解下如何利用Monitor 平台提供的这些功能去分析定位问题。

4 分析过程

4.1 指标分析

在分析具体问题之前，我们可以先在monitor 上实时监控某一时段的一些指标参数，如系统物理内存，堆内存，cpu 负载，web 请求时间等。通过这些指标可以推测大体的问题和分析方向，比如cpu 负载高，排除了硬件本身的问题后，判断可能是代码问题，应该找cpu 占用最高的线程堆栈信息进行分析，如果是sql 执行时间较长，可以从慢查询角度去分析等等。

1. 步骤：

（1）通过monitor 上左侧导航的指标监控进入，勾选对应的示例，勾选所需要的指标参数。需要比较关注的指标是堆内存，非堆内存，系统cpu 负载，sql 执行的时间等，观察堆内存是否达到了最大值，是否频繁出现full gc？非堆内存的元空间大小，是否影响类加载？

4.2 定位具体模块

从上面的指标可推测到大致瓶颈在哪里，但需要定位更具体的问题或者在排查生产环境出现异常问题的时候，我们需要根据问题暴露的关键信息确定具体是哪个模块或者哪个请求产生的。

1.步骤：

（1）打开页面或者进行操作时，浏览器打开调试模式（浏览器按键盘F12 按键或者右键检查元素打开调试模式），切换到调试模式Network 下面，找到该次操作对应的请求地址（为防止请求太多，可先清空之前的请求）。由于与前端的一次交互可能产生多个请求，如果是性能问题，可定位到最耗时的请求进行分析。如下图所示

（2）获取traceId：选中请求链接，在当前请求headers 中获取traceId，如下图所示

4.3 调用链分析

我们都知道苍穹是微服务的架构，在微服务架构下，一个http 请求从发出到响应，中间可能经过了N 多服务的调用，或者N 多逻辑操作。在分析耗时操作、某个服务性能瓶颈，或者某个逻辑操作的执行情况时，调用链可以帮助我们快速定位是哪个服务调用存在问题，苍穹的微服务已经整合了zipkin，我们可以直接在monitor 中使用。

1. 步骤:

（1）通过monitor 上左侧的调用链进入zipkin，根据traceId 查找

4.4 日志分析

确定了具体请求后，需要获取请求对应的日志，从日志着手分析问题。

1.步骤：

（1）根据traceId 查找当前请求链路日志：monitor 左侧导航点击日志查询，可输入traceId，关键字，时间等进行过滤

注：公有云环境，可使用天梯（https://ops.kdcloud.com/）查询

2. 分析小技巧：

（1）通常情况下，我们根据tarceId 过滤后，日志会比较多，如果我们已经定位到了具体需要分析的代码块，可以输出其他级别的日志（日志输出需要符合苍穹定制化开发规范，不是错误信息不要输出error 级别）加以区分，方便快速定位；

（2）在日志中，通常关注比较多的是执行的总耗时，是否存在慢查询，是否存在异常等；

（3）简单案例分析：

以上面两张图为例，我们可以获取的信息是，第一张图的时间是该请求列表加载时间，耗时50 多s；第二张图是该列表对应的sql 执行的时间，也是50 多s，基本定位该请求性能的瓶颈在于慢查询，我们可以将该sql 拷贝到查询分析器或者Navicat 中查看其执行计划，进行sql 优化。（参考苍穹定制化开发性能优化专题系列（一）的相关内容，此处不再讲述慢sql 如何优化）

（4）如果已经定位是慢查询问题，可直接根据traceId，关键字等过滤出慢查询相关日志；

4.5 堆栈分析

如果卡顿较明显，比如需要几分钟以上才加载成功或者是页面一直在加载中，甚至是超时的，一般情况下只看日志比较难能定位问题，我们可以使用堆栈查询功能进行分析。

1. 步骤：

（1）通过monitor 上的注册中心，找到对应的服务实例，点击线程堆栈查看对

应线程的统计信息

（2）也可以点击导航左侧的线程监控，选择对应的微服务和实例，通过一些关键字过滤找到对应的线程

5 总结

我们在文章的开头讲述了可能存在影响因素的思路，对于不同的架构其实影响点也是不同的，但是对于开发人员而言，在应用层面上考虑的无非是CPU 使用率，内存使用情况，磁盘IO，代码设计等这几个问题，上面的分析过程也讲述了在苍穹如何处理此类问题，最核心的还是定位模块，查找日志，分析堆栈，找对最耗时和有异常的服务/代码。定位问题之后，性能优化也是一个比较棘手的问题，大家在优化过程中可以参考性能优化系列上两期将的指南。

注：以上的定位排查分析方式覆盖不全，如有小伙伴有更多的想法，欢迎进行补充交流~

关于调用链和线程堆栈更详细的分析内容请期待下一期~

下载路径：云之家企业云盘

企业文件->【苍穹平台】共享资料库05->定制化开发标准化工具包->03开发规范

如有疑问或者更好的建议，欢迎小伙伴留言或者私聊~