云架构系统如何做性能分析?| 实战干货

本文涉及的产品
云防火墙,500元 1000GB
日志服务 SLS,月写入数据量 50GB 1个月
性能测试 PTS,5000VUM额度
简介: ![](https://ceshiren.com/uploads/default/original/3X/e/3/e30e5d3af75b37519633f5f5b2ef7ff914034125.jpeg)性能分析一直是性能实施项目中的一个难点。对于只做性能测试不做性能分析的团队来说,总是不能把问题非常显性地展示出来,不能给其他团队非常明确的引导。对于这种类型的测试实施,只能把问题抛出来,让

性能分析一直是性能实施项目中的一个难点。对于只做性能测试不做性能分析的团队来说,总是不能把问题非常显性地展示出来,不能给其他团队非常明确的引导。对于这种类型的测试实施,只能把问题抛出来,让其他相关团队去查。沟通成本很高。
而一个成熟的性能团队应该是要把问题点分析出来,给其他团队或责任人非常明确的瓶颈点,以加快问题的处理进度。
从完整的分析思路上考虑。有两个要点:分段和分层。

如上图所示,分段就是要把 1-6 以及在 server1/2、DB 上消耗的时间都统计出来。分层就是要把上图中各种不同颜色的层都分析到。
可以使用的方法在不同的项目中各不一样,取决于应用的架构。
性能分析的深度要到什么程度为宜呢?主要是看组织的结构和项目中涉及到的人的职责定义。要把握的深度就是让各团队没有技术上的 Gap。这一点非常重要。
从实际的操作层面来说,因为性能主要是在大压力下是否能保持住时间的可接受性。所以主要把握如下几点:
1.从响应时间到具体的代码;
2.从响应时间到具体的 SQL;
3.从响应时间到具体的配置
有了这几个层面的分析,基本上就可以确定一个问题的瓶颈点了。
在数据理解上,有两个阶段:
1.知道计数器的含义:
这个阶段看似简单,但能记得住那么多 performance counter 的人并不多,这个记不住倒是没有太大关系,遇到就查,多遇几次自然就记住了;

比如,对于上图来说,要理解的计数器就是 await 和 svctm,await 高是肯定存在问题。如果要判断问题是严重不严重还要看另一个计数器就是 avgqu-sz,它是队列长度。svctm 是平均每次 io 的时间(单位:ms)。
再来看看 CPU 的计数器。

CPU 的计数器在 top 中有 8 个,在 mpstat 中多两个。在上面的计数器中,通常的说法是,us CPU 是用户态的,如果这部分高,通常是应用代码消耗的;sy CPU 是系统态的,如果这部分高,通常是 os 层的配置有问题。
这种说法在大部分情况下是合理的,但是不管是 us CPU 还是 sy CPU,高和低都只是问题的表现。分析到此并不是性能分析的结束,下面要找到的就是为什么这么高?这一步是非常关键的。一般情况下,分析路径是:

所以下一步就很清晰了,就是找哪个进程、线程消耗的 CPU 高,进而查到代码。
2.知道计数器的值之间的关系:
这个阶段大部分人都需要好几年的时间才能完全掌握常规的计数值,之所以说只能掌握常规的计数值是因为有一些数值的联动关系不是那么容易碰得到。
比如说 CPU 模式对 TPS 和 RT 的影响,大部分人都是拿到硬件的时候都是 Full performance mode 了,并不关心还有没有其他的模式;比如说网络计数值导致的 TPS 有规律或无规律的抖动。
这些场景都要求做性能分析的在看到某个计数值的时候能有直接的反应,但是这一点非常难。因为数值的高低对大部分人来说就是一个谜,经常有人问这样的问题,这个值是高还是低,应该说只要不是一起工作的人都说不上来某个值是高还是低(当然对一些非常清晰的场景是比较容易判断的),合理还是不合理。

如上图所示:procs 的 b 列很高,这个值的含义是等 io 的进程数,它在上图中和 CPU wa 列是对应的。同时,也和 IO 的 bi、bo 列是对应的,从这几个值关联来看下步是要看哪个进程消耗的 IO 多了。
能经过数据理解的这一层次,才算是到了中级性能分析工程师的能力。
4.1 压力工具的曲线
做性能分析,看曲线是最直接了当的。压力工具可以给我们的明确的信息就是这个系统是不是有问题的,这也是压力工具自身曲线可以明确显示的唯一的信息。请看下面几张图:
TPS 图:

响应时间图:

递增线程图:

怎么理解这几张图呢?
先看张线程图。可以知道多个业务都有设置并发递增线程。这个图能给的信息就是这个且只有这个。
结合 TPS 图可以知道,在第三个梯度的时候,TPS 到了峰值。在第四个梯度的时候,TPS 已经开始下降了。
再结合响应时间图,在第三个梯度的时候,响应时间是明显地抬了头。后面响应时间在持续增加,每个梯度都有增加。
这时候有两件动作可做:
1.修改场景接着测试。
如何修改场景?把线程数降低。降到在梯度增加的过程中,响应时间没有明显增加的趋势之后再来看 TPS 是什么趋势。对于一个系统来说,响应时间有增加、TPS 没有增加(或有下降)、线程数有增加,这几个判断就明确说明了系统是有瓶颈的,并且也仅能说明这一点。
2.在当前场景下,分析瓶颈点,看时间消耗在哪个环节上。
这两个动作取决于目标,如果 TPS 在第三个梯度上已经达到了业务指标,那可以不做优化。所以第一个动作的前提是 TPS 目标已达到。
显然,第二个动作就是 TPS 目标还未达到。
当然有人提出 TPS 目标达到了,有瓶颈也是需要优化呀?在这一点上,就要看做决定的人怎么考虑了,因为优化是要付出成本的。接下来再说另一种曲线。
4.2 系统监控曲线。
由于操作系统级的监控有非常多的监控曲线,这里拿一个内存的来举例子。
内存曲线图:

对 linux 操作系统来说,操作系统的内存会慢慢被分配掉,变成 caching memory。所以如果只看 available memory 的意义并不大,需要 -/+ buffer/cache 之后再看可用内存。这一点大家都清楚。
那么上面是不是说内存没有问题呢?当然不是。因为内存不仅被用光了,而且还断了一段,后面又有了数据,接着又用光,又断了一段时间。红色的框中,是有问题的,因为这一段连数据都没有抓到,抓数据的进程应该是没了。
所以 available memory 的下降并不是要关注的重点,-/+ buffer/cache 之后的 available memory 才是要关注的重点。另外从上图中看到的断掉的时间点也是要分析的重点。
另外,上图中,蓝框内内存一直在很低的状态,后面却突然升高了那么多。这里也是要分析的重点。
JVM 图

对 JVM 曲线来说,也是要看趋势的,基础知识是 jvm gc 的逻辑。YGC 一直在做,heap 一直在增加,这个过程是不是正常的呢?对于没有做过 Full GC 的 JVM 来说,heap 是有增加的趋势是可以理解的,但是这个 “理解” 需要一个前提,就是业务有没有增量。
如果是有业务的增量,上图就是正常的;如果没有业务增量,上图就是不正常的,那什么样的才是没有业务增量的正常呢?看下图:

上图就明显是个非常正常的 JVM。
对于曲线的理解,首先要知道的是数据的来源和含义。在性能分析中,有很多曲线的趋势都不是可以直接指明问题的,只能通过收集全部的信息来做完整的分析才能判断问题存在点。
上面举了两个例子的角度分别是:压力工具生成的曲线和后端服务器相应的工具生成的曲线。就是为了说明一点:曲线分析是在关注所有的层面。
连续三天,晚上在执行一个业务场景持续几个小时之后,就开始连续报错。服务器连不上了。但在报错的一开始,并不是全部都报错,而是有部分是可以成功的,但是过一段时间之后,所有业务都报错了。次日来看,发现进程不见了。
本来以为是进程崩溃退出了,那日志中应该留下来些证据。但是打开了日志查看了一下,没有任何异常信息。连续三天都出现。就登录 zabbix 上去看了一下主机资源。


红框内的是出现问题的时间段。看到这里似乎明白了为什么并不是所有业务都失败。因为内存还有上升的这个阶段。但是为什么降到底之后又上去,再次降到底呢?先看一下拓扑图。
两个主机,四个进程,既然进程都没了,应该不是一块没的,要不然不会还有业务可以成功。
翻了一下应用日志,确实没有什么和进程消失相关的错误信息。
既然是进程没了,日志也没信息,那下一步是什么呢?就是看 dmesg 了。系统日志总有些信息吧。进程死了无非就那么几个地方能看到。
4.应用日志;
5.出 dump;
6.系统日志。

在这里提醒一下,最好直接运行 dmesg 命令,而不是去看 /var/log/dmesg 文件。因为命令中会把其他 message 也放进去,会全一点。
查看了 dmesg 之后,发现如下信息:

从时间上来算一下。系统运行时间 41.45 天,确实和第一个图上的 21:30 的时间对应得上。从这里来看是 6341 进程被杀了。
再看第二个图:

再来算一下时间。41.55 天,和第一个图上的 11:45 能对得上。
看来是 OOM Killer 主动把这两个进程给杀了。从下面的信息来看是这两个进程消耗 linux 主机的物理内存和虚拟内存太大,以致于把内存都给消耗光了,最后 OOM Killer 就站出来主持公道了:小子挺横呀,老子分给你了一亩三分地,不好好呆着,敢来抢地盘,干它!
于是就真的被 kill 了。
既然知道了内存消耗得多,那这个场景就好复现了。接着用原场景测试。看下 Java 进程的内存,Java 的内存分成堆内堆外。因为是操作系统的 OOM Killer 干掉的,所以基本上可以排除堆内的内存导致的。因为堆是有限制的嘛。
既然这样,那就是堆外。打个 threaddump 看看。

怎么这么多线程?并且也看到了开发的包名。
把这个路径给了开发之后,让他们翻翻这一段的源码,看到类似如下内容:Threadthread=newThread();(当然还有调用的代码,就不一一罗列了)开发这才知道是为啥有这么多新创建的线程。于是拿回去改去了。
用户递增图:

TPS 图:

通过查看网络连接状态,看到有大量的 TIME_WAIT 出现。

尝试分析过程如下:
1.为 TIME_WAIT 修改 TCP 参数
通过检查 sysctl.conf,看到所有的配置均为默认,于是尝试如下修改:

  1. net.ipv4.tcp_tw_recycle = 1
  2. net.ipv4.tcp_tw_reuse = 1
  3. net.ipv4.tcp_fin_timeout = 3
  4. net.ipv4.tcp_keepalive_time = 3

回归测试,问题依旧。
2.修改 Nginx 的 proxyignoreclient_abort
考虑到当客户端主动断开时,服务器上也会出现大量的 TIME_WAIT,所以打开 proxy_ignore_client_abort,让 Nginx 忽略客户端主动中断时出现的错误。proxy_ignore_client_abort on;修改后,重启 Nginx,问题依旧。
3.修改 tomcat 参数
查看 tomcat 的 server.xml 时,看到只设置了 maxthreads。考虑到线程的分配和释放也会消耗资源。所以在这里加入如下参数:maxKeepAliveRequests="256"minSpareThreads="100"maxSpareThreads="200"。
重启 tomcat,问题依旧。
4.换 Nginx 服务器
在分段测试的时候,看到通过 Nginx 就会出现 TPS 上到 300 就会下降的情况,所以考虑是 Nginx 机器的配置问题,于是换了在另一台机器上重新编译了 Nginx,所有的操作系统都是一样的配置。
通过新的 Nginx 做压力,问题依旧,所以可以判断这个问题是和操作系统的配置有关,和 Nginx 本身的配置无关。
5.停掉防火墙
和网络连接有关的内容,剩下的就只有防火墙了。于是执行了:Serviceiptables stop。在执行了之后,看到 TPS 立即就上去了。并且可以增加得非常高。从而定位,TPS 的下降和防火墙有关。
6.系统日志
进到 /var/log,查看 messages,看到大量的如下信息:
11.Nov 4 11:35:48 localhost kernel: __ratelimit: 108 callbacks suppressed
12.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
13.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
14.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
15.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
16.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
17.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
18.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
19.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
20.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
21.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
22.Nov 4 11:35:53 localhost kernel: __ratelimit: 592 callbacks suppressed
23.Nov 4 11:35:53 localhost kernel: nf_conntrack: table full, dropping packet.
24.Nov 4 11:35:53 localhost kernel: nf_conntrack: table full, dropping packet.
25.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
26.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
27.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
28.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
29.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
30.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
31.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
32.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
33.Nov 4 11:35:58 localhost kernel: __ratelimit: 281 callbacks suppressed
34.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
35.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
36.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
37.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
38.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
39.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
40.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
41.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
42.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
43.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
44.Nov 4 11:36:14 localhost kernel: __ratelimit: 7 callbacks suppressed
7.参数修改
因为出现大量的 nf_conntrack:table full,dropping packet。所以在 sysctl.conf 中加入了如下参数设置。
45.net.netfilter.nf_conntrack_max = 655350
46.net.netfilter.nf_conntrack_tcp_timeout_established = 1200
修改参数后,执行:Serviceiptables start.可以看到,TPS 仍然可以很高,从而解决问题。
解决问题后的 TPS 图:

上图中有两次 TPS 下降的过程是因为又尝试了修改防火墙的参数配置,重启了两次防火墙。
综上,对于性能分析来说,不仅是现象的解释,还有瓶颈的定位及问题的解决。这些工作所要求的基础知识较多,一个人力不能及的时候,就需要一个团队来做。关键是要把问题分析得清晰透彻。(end)
由霍格沃兹测试学院校长思寒老师、高楼老师以及来自腾讯、阿里巴巴的 BAT 多位资深性能测试技术专家联袂打造。3 个月大咖带你掌握性能测试实战三大核心技能:性能压测体系、性能监控体系、性能分析体系。一步步实战进阶,挑战性能之巅!

加小助手微信,回复「性能测试」入群咨询!
群内有多重福利:
福利一:免费学习性能测试实战大咖公开课+PPT资料!
《从黑白风格到Grafana图型化界面性能分析报告》
《性能分析大师如何给出关键论据分析需求的》
《性能测试与性能分析的价值体现》
福利二:抽奖赠送性能测试经典好书《性能之巅:洞悉系统、企业与云计算》。
福利三:优惠价报名《高级性能测试实战训练营》课程。

相关文章
|
8天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
128 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
2天前
|
机器学习/深度学习 算法 数据可视化
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
本文探讨了在量化交易中结合时序特征和静态特征的混合建模方法。通过整合堆叠稀疏降噪自编码器(SSDA)和基于LSTM的自编码器(LSTM-AE),构建了一个能够全面捕捉市场动态特性的交易系统。SSDA通过降噪技术提取股票数据的鲁棒表示,LSTM-AE则专注于捕捉市场的时序依赖关系。系统采用A2C算法进行强化学习,通过多维度的奖励计算机制,实现了在可接受的风险水平下最大化收益的目标。实验结果显示,该系统在不同波动特征的股票上表现出差异化的适应能力,特别是在存在明确市场趋势的情况下,决策准确性较高。
16 5
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
|
13天前
|
机器学习/深度学习 人工智能 并行计算
【AI系统】Kernel 层架构
推理引擎的Kernel层负责执行底层数学运算,如矩阵乘法、卷积等,直接影响推理速度与效率。它与Runtime层紧密配合,通过算法优化、内存布局调整、汇编优化及调度优化等手段,实现高性能计算。Kernel层针对不同硬件(如CPU、GPU)进行特定优化,支持NEON、AVX、CUDA等技术,确保在多种平台上高效运行。
65 32
|
13天前
|
存储 机器学习/深度学习 人工智能
【AI系统】计算图优化架构
本文介绍了推理引擎转换中的图优化模块,涵盖算子融合、布局转换、算子替换及内存优化等技术,旨在提升模型推理效率。计算图优化技术通过减少计算冗余、提高计算效率和减少内存占用,显著改善模型在资源受限设备上的运行表现。文中详细探讨了离线优化模块面临的挑战及解决方案,包括结构冗余、精度冗余、算法冗余和读写冗余的处理方法。此外,文章还介绍了ONNX Runtime的图优化机制及其在实际应用中的实现,展示了如何通过图优化提高模型推理性能的具体示例。
45 4
【AI系统】计算图优化架构
|
3天前
|
机器学习/深度学习 前端开发 算法
婚恋交友系统平台 相亲交友平台系统 婚恋交友系统APP 婚恋系统源码 婚恋交友平台开发流程 婚恋交友系统架构设计 婚恋交友系统前端/后端开发 婚恋交友系统匹配推荐算法优化
婚恋交友系统平台通过线上互动帮助单身男女找到合适伴侣,提供用户注册、个人资料填写、匹配推荐、实时聊天、社区互动等功能。开发流程包括需求分析、技术选型、系统架构设计、功能实现、测试优化和上线运维。匹配推荐算法优化是核心,通过用户行为数据分析和机器学习提高匹配准确性。
22 3
|
2天前
|
弹性计算 Java 数据库
Web应用上云经典架构实战
本课程详细介绍了Web应用上云的经典架构实战,涵盖前期准备、配置ALB、创建服务器组和监听、验证ECS公网能力、环境配置(JDK、Maven、Node、Git)、下载并运行若依框架、操作第二台ECS以及验证高可用性。通过具体步骤和命令,帮助学员快速掌握云上部署的全流程。
存储 人工智能 自然语言处理
48 6
|
1天前
|
监控 Java 数据中心
微服务架构系统稳定性的神器-Hystrix
Hystrix是由Netflix开源的库,主要用于微服务架构中的熔断器模式,防止服务调用失败引发级联故障。它通过监控服务调用的成功和失败率,在失败率达到阈值时触发熔断,阻止后续调用,保护系统稳定。Hystrix具备熔断器、资源隔离、降级机制和实时监控等功能,提升系统的容错性和稳定性。然而,Hystrix也存在性能开销、配置复杂等局限,并已于2018年进入维护模式。
10 0
|
1天前
|
前端开发 搜索推荐 安全
陪玩系统架构设计陪玩系统前后端开发,陪玩前端设计是如何让人眼前一亮的?
陪玩系统的架构设计、前后端开发及前端设计是构建吸引用户、功能完善的平台关键。架构需考虑用户需求、技术选型、安全性等,确保稳定性和扩展性。前端可选用React、Vue或Uniapp,后端用Spring Boot或Django,数据库结合MySQL和MongoDB。功能涵盖用户管理、陪玩者管理、订单处理、智能匹配与通讯。安全性方面采用SSL加密和定期漏洞扫描。前端设计注重美观、易用及个性化推荐,提升用户体验和平台粘性。
11 0
|
15天前
|
机器学习/深度学习 人工智能 调度
【AI系统】推理引擎架构
本文详细介绍了推理引擎的基本概念、特点、技术挑战及架构设计。推理引擎作为 AI 系统中的关键组件,负责将训练好的模型部署到实际应用中,实现智能决策和自动化处理。文章首先概述了推理引擎的四大特点:轻量、通用、易用和高效,接着探讨了其面临的三大技术挑战:需求复杂性与程序大小的权衡、算力需求与资源碎片化的矛盾、执行效率与模型精度的双重要求。随后,文章深入分析了推理引擎的整体架构,包括优化阶段的模型转换工具、模型压缩、端侧学习等关键技术,以及运行阶段的调度层、执行层等核心组件。最后,通过具体的开发流程示例,展示了如何使用推理引擎进行模型的加载、配置、数据预处理、推理执行及结果后处理。
44 0
下一篇
DataWorks