性能测试基础05 - 性能瓶颈分析

已于 2023-08-23 01:54:23 修改
阅读量276 收藏 3
点赞数
分类专栏： 性能测试 文章标签： grafana
于 2023-08-17 15:49:46 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_71999197/article/details/132337413
版权

一、线程数量 如何确定？

  1. 通过基准测试获取基准响应时间：
    15ms

  2. 单线程产生的并发量(理论上是tps) = 1000ms/响应时间(ms)：
    1000/15🟰66

  3. 线程数量 = 目标并发量 / 单线程产生并发量：
    800 / 66= 12
    目标并发量上浮取15个线程

  4. 实际性能测试过程中 - 线程数往往是过载：
    20个

  5. 还有一种算法
    能接受的最大响应时间 去代入上面的公式：
    1000 / 200 = 5
    800 / 5 = 160个线程

二、如何定义所谓的瓶颈

  • 程序性能指标不达标

    • 吞吐量

    • 响应时间

    • 错误率

    • 资源占用率

三、网络瓶颈分析与调优方向

3.1 检查网络速度 - iperf3

工具 iperf3 测试两个服务器 之间的 带宽速度 测速

3.2 由吞吐量计算网络带宽

计算 -- 520/s 吞吐量 占用多大网络带宽（吞吐量 * 响应大小 * 8bit）

  • 传输内容大小（响应头+响应体）

    • 单词响应内容大小0.33KB

    • http头大小普遍1KB左右，有些响应头还会更大

    • 每次传输响应数据在，1.3KB左右

  • 实测过程中占用网络带宽

    • 520*1.3 = 网络每秒传输676KB

    • 占用带宽 = 676KB * 8 = 5408kbps 约等于5Mbps左右

  • 检查网络带宽

    • 应用服务器带宽 -- 只有 5M兆

    • 推测 -- 性能瓶颈的原因在这

    • 验证 -- 提高性能测试环境的带宽

3.3 网络监控 - iftop

iftop (全称应该是 interface top) 是查看网络实时流量的工具，可以监控各个应用程序的流量

常用命令：iftop -i enp0s8 -n 

3.4 优化建议

 

硬件：升级机器，

软件：优化程序

  • 压缩数据传输的大小

    • 压缩源数据

    • 服务器层面 gzip压缩传输

    • 减少不必要数据传输

四、磁盘瓶颈分析与调优方向

4.1 程序使用场景

  • 日志文件

  • 附件上传存储

  • 数据库系统 - 表数据读写

  • 程序本身的代码，配置文件 都是在磁盘存放起来，需要加载到内存

4.2 磁盘监控 iotop

iotop -- only 查看某进程磁盘读写情况

a1cf814370dd81ae49f01f1bba8ce003.jpeg

 3.3 优化建议

WEB网站 -- 每一张图片 很大

  • 同时也会占用大量的 网络带宽

  • 占用大量的磁盘 I/O

日志 -- 控制详细程度

  • 不同的日志级别

    • 生产 warn/error

    • 开发 info/debug

  • 磁盘空间是有限的， 监控 磁盘空间的占用增长情况

  • 目前的系统里边 - 主要 还是 数据库系统 用磁盘比较多

五、CPU瓶颈分析与调优方向

5.1 top查看CPU运行情况

5.2 性能测试过程：

负载测试下：

  • 如果吞吐量达到了瓶颈，而CPU资源占用不高，当你增加了并发量，而CPU并没有随之变高：就要考虑程序代码或者操作系统配置问题，例如：涉及Jvm 程序 多线程机制

 性能测试过程中，CPU占用已经很高

六、JAVA程序调优实战分析

6.1 JVM 核心知识：

程序计数器（线程私有，记录线程上次执行到哪里，下一步执行什么）：下一条需要执行的字节码指令：分支、跳转、循环、异常处理、线程恢复等基础操作都会依赖计数器来完成。每个线程都有独立的程序计数器，用来在线程切换后能恢复到正确的执行位置，各条线程之间的计数器互不影响，独立存储。

栈（线程私有）：后进先出，记录当前正在执行的方法

方法区/元数据区（线程共有）：存储已被虚拟机加载的类信息、常量、静态变量、JIT（just in time,即时编译技术）编译后的代码等数据

堆（线程共有）：存储Java对象实例的内存区域

6.2 JVM 资源监控工具

jmap，jconsole，jvisualvm

JVM集群监控体系-测试过程/结果分析中看grafana（需要开发配合采集）

6.3 优化建议

1. 性能测试过程 - 服务器内存资源够用，但是程序性能达到了瓶颈

可疑原因：内存配置太小，没有榨干服务器内存资源。或者是测试场景中的并发量不够（要监控 测试过程中，JVM自身的内存是否被用完，如果没用完，就加大并发量）

通过查看 JVM的 内存配置 ，是否用到了 机器的大部分内存

验证：

  • 1. 加大并发 -- 排查性能测试并发不够的问题

  • 2. 加大内存 -- 在加大内存之后，性能是否有提升，-Xms（堆内存最小值）-Xmx（堆内存最大值）

2. 性能测试过程 - 服务器CPU资源够用，但是程序性能达到了瓶颈

可疑原因：程序配置的线程数太少，没有榨干服务器硬件资源。或者是测试场景中的并发量不够

请求处理的线程池大小线程参数调整

 

  • WEB服务 --- 处理请求时候，会用到线程池

    • 不限于Tomcat，jetty，netty，weblogic，包括其他语言 也有类似的机制

  • 比如tomcat的3个参数：acceptCount、maxConnections、maxThreads

    • accept队列的长度；当accept队列中连接的个数达到acceptCount时，队列满，进来的请求一律被拒绝。默认值是100

    • Tomcat在任意时刻接收和处理的最大连接数。当Tomcat接收的连接数达到maxConnections时，Acceptor线程不会读取accept队列中的连接；这时accept队列中的线程会一直阻塞着，直到Tomcat接收的连接数小于maxConnections。如果设置为-1，则连接数不受限制。

    • 请求处理线程的最大数量。默认值是200

3. 并发量少，但是CPU资源占用量大

可疑原因：少量线程占用了大量的系统资源例如： 1. 单线程占用CPU 100% （死循环、数据太多循环N多次处理）2. 1个请求会导致大量的线程被创建 （开发人员写业务逻辑代码也用到多线程）

排查方式：

  1. top+jstack寻找最耗CPU的进程和线程
  2. 基于arthas阿里提供的，dashboard 整体仪表盘，thread -n 5 展示最忙的前5个线程

七、JAVA程序GC机制及性能稳定性调优分析

format,png

 

1. 分代

  • 新生代 - ede，（8：1：1）

    • 新生代-survivor 1

    • 新生代-survivor 2

  • 老年代（新：老= 1：2）

    • 老年代 - 超级大的对象 和 经历多次新生代GC依然存在的对象。

  • 特殊 - 永久代【元数据空间】

2. STW概念（stop the world）

  • 和性能有关，GC时程序停止

  • 一个请求 -- 处理时间业务代码 执行时间 + GC垃圾回收时间

3.GC

  • minor gc 小范围GC

    • 新生代

    • 时间一般比较短

  • full gc 大范围GC

    • 所有的堆空间、元数据空间

    • 导致 程序中断的时间比较长

7.1 StackOverflowError-栈内存溢出

可疑原因：递归调用

方法：尝试修改配置增加JVM每个线程栈内存的大小

7.2 实战：OutOfMemoryError

可疑原因：持久性压力测试，程序内存占用逐步增高，最终挂掉突然大量并发，内存不够用

  • java.lang.OutOfMemoryError: unable to create new native thread

    • Java应用程序已经达到了它可以启动的线程数的限制

  • java.lang.OutOfMemoryError: Metaspace1.8+ java.lang.OutOfMemoryError: PermGen space

    • -XX:MaxPermSize=512m

    • 加大元数据空间的内存，或者检查元数据空间占用是否合理

    • class 类加载的太多，动态创建了很多class类

  • java.lang.OutOfMemoryError: Java heap spacejava.lang.OutOfMemoryError:GC overhead limit exceeded

    • 加大堆内存，或者检查内存占用是否合理

    • 程序调优 - 获取内存快照 - 找到内存占用比较大的对象，让开发去修改

7.3 性能测试中，吞吐量呈现出波浪状。性能稳定性调优

可疑原因： JVM 垃圾回收 导致STW，产生时间停顿

调整GC参数

八、Mysql数据库性能测试及瓶颈分析调优思路

8.1 Mysql 独立的监控指标

        grafana + prometheus + mysql

8.2 数据库调优思路汇总

瓶颈：

  • 资源不够用CPU，网络资源，磁盘资源，内存

  • 响应时间  - 慢查询日志

  • 数据库连接池线程数量

  • 查询-调优分析：

    • 使用索引

    • 减少表关联join

    • 搜索场景严禁左模糊或者全模糊

    • 大量更新可以用批处理，及时关闭事务，非必要不要主动锁数据

九、Nginx负载均衡集群架构性能测试及瓶颈分析调优思路

Nginx 性能监控

        grafana + prometheus + nginx

可疑原因：

  • Nginx 瓶颈分析

    • 资源占用：磁盘网络内存CPU

    • 请求是否堆积：write，wait，read，active

Nginx 调优方向：

  • Nginx运行工作进程数量
  • Nginx运行CPU绑定
  • 三种方式：轮询，权重，ip_hash

十、Redis高并发缓存架构性能测试及瓶颈分析调优思路

10.1 Redis 监控体系

        grafana + prometheus + redis

10.2 Redis 调优建议

缓存预热，缓存击穿，缓存雪崩

Redis本身的性能足够逆天，大部分的问题在于 开发人员没有用好Redis

十一、MQ高并发异步消息架构性能测试及瓶颈分析调优思路

activemq，rabbitmq，kafka

监控体系：官方

不同的消息模式：

  • sync同步模式

    • 发送消息采用同步模式，这种方式只有在消息完全发送完成之后才返回结果，此方式存在需要同步等待发送结果的时间代价

    • 具有内部重试机制

  • async异步模式

    • 发送消息采用异步发送模式，消息发送后立刻返回，当消息完全完成发送后，会调用回调函数sendCallback来告知发送者本次发送是成功或者失败。异步模式通常用于响应时间敏感业务场景，即承受不了同步发送消息时等待返回的耗时代价

    • 同步发送一样，异步模式也在内部实现了重试机制，默认次数为2

    • 测试的时候：要注意， 如果发送完毕之后，程序就挂掉了， 那么对于数据处理是否存在问题

      • 程序在收到 MQ 处理失败的callback回调消息之后，要进行相对应重试设计

  • one-way生产者单向发送

    • 采用one-way发送模式发送消息的时候，发送端发送完消息后会立即返回，不会等待来自broker的ack来告知本次消息发送是否完全完成发送。这种方式吞吐量很大，但是存在消息丢失的风险，所以其适用于不重要的消息发送，比如日志收集

    • MQ 出问题的情况还是比较少的

 

 

 

Eddie_Han
关注
  • 0
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
我终于知道高工是如快速分析线上程序性能瓶颈了（CPU篇）
suojizhu3034的博客
03-12 46
显示 CPU 使用情况，包括用户空间占用CPU百分比（us）、内核空间占用CPU百分比（sy）、用户进程空间内改变过优先级的进程占用CPU百分比（ni）、空闲CPU百分比（id）、等待 I/O 完成所占用的 CPU 时间的百分比（wa）、硬件CPU中断占用百分比（hi）、软中断占用百分比（si）、虚拟机占用 CPU 时间的百分比（st）等信息。当有硬件中断时，中断处理会打断进程的正常调度和执行，会将进程内核态的上下文保存下来，转而执行中断，这样在中断完成后，进程仍能恢复原来的状态继续运行。
软件测试中性能测试－－瓶颈分析方法
03-23
分析方法软件测试中性能测试－－瓶颈分析方法性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载...
LoadRunner性能测试工具---测试结果样例分析
02-24
本文来自于csdn，本文简单介绍了本次性能测试的目的和分析，看看本次测试是否达到了预期的性能指标，其中又有哪些性能隐患，该如何解决。接触性能测试一年多了，在机房也为多个系统做过负载和压力测试，还原了上百人的测试操作，但是对于LR测试结果的分析一直都是一个瓶颈，偶然机会让我遇到了这篇文章，一名专业测试人员的系列博客，让我对于性能测试的理解又深入了一个层次，在此分享给大家。LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析，如图1-1所示。性能测试结果分析的
详细的性能分析和调优的示例过程：
fishlovejavaa的博客
05-14 307
通过上述步骤，你不仅解决了当前的数据库性能问题，还建立了一个长期的数据库性能管理机制。最后，你记录了整个性能分析和调优的过程，建立了性能基线，并设置了持续监控策略，以便及时发现并解决未来的性能问题。你决定对该表进行分区，以提高查询效率。利用Percona Toolkit等工具，进行了更深入的性能分析，发现了一些之前未注意到的性能问题。为了进一步加速热点数据的访问，你引入了Redis作为缓存层，将频繁访问的数据存储在内存中。通过调整数据库配置参数，如增加缓冲区大小，减少连接超时时间，优化了数据库的运行效率。
性能测试的结果如何解读和分析（超详细）
最新发布
huace3852的博客
05-21 679
3. 95%响应时间：95%响应时间是指系统处理请求所需时间中，排除最慢5%的请求后的平均时间。1. 平均响应时间：平均响应时间是指系统处理请求所需的平均时间。较长的最大响应时间可能意味着系统在某些情况下的性能较差，用户可能会遇到较长的等待时间。需要关注最大响应时间是否超过了用户可接受的阈值。1. 响应时间：响应时间是指系统处理请求所需的时间，通常以平均响应时间、最大响应时间、95%响应时间等指标来衡量。5. 进行试验和评估：在系统开发的早期阶段，可以进行一些试验和评估，以了解系统在不同负载下的性能表现。
windows 资源监控常用指标分析
lsharp的专栏
04-09 7170
<br />怀疑内存不足时：<br />方法1：<br />【监控指标】：Memory Available MBytes ，Memory的Pages/sec, page read/sec, Page Faults/sec<br />【参考值】：<br />如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。<br />Page/sec 推荐00-20（如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题）。<br /><br />方法2：根据Physica
使用 iperf 和 iftop 测试网络带宽
Laurence的技术博客
12-09 1639
有时候，我们需要确切地知道服务器在当前网络环境下所能达到的上行和下行的网络带宽是多少，这对于测试一些上传或下载的作业效率非常重要。我们以位于AWS VPC 环境中的 EC2 为例，介绍一下如何实测出 EC2 节点所能达到的最大带宽。我们以 m5.4xlarge 这一机型为例，根据 AWS 官方文档的介绍：https://aws.amazon.com/ec2/instance-types/m5/，该型实例可以达到的最高带宽是 10 Gbps，我们将使用两台 m5.4xlarge，通过 iperf 来实测一下两
算法笔记2-算法性能分析
dc爱傲雪和技术
12-24 43
算法导论给出的解释：大O用来表示上界的，当用它作为算法的最坏情况运行时间的上界，就是对任意数据输入的运行时间的上界。面试中说道算法的时间复杂度是多少指的都是一般情况。在决定使用哪些算法的时候，不是时间复杂越低的越好（因为简化后的时间复杂度忽略了常数项等等），要考虑数据规模，如果数据规模很小甚至可以用O(n^2)的算法比O(n)的更合适（在有常数项的时候）。就像上图中 O(5n^2) 和 O(100n) 在n为20之前 很明显 O(5n^2)是更优的，所花费的时间也是最少的。
性能：性能分析思路
OceanStar的博客
11-02 3763
性能分析能力阶梯图 工具操作：包括压力工具、监控工具、剖析工具、调试工具。 数值理解：包括上面工具中所有输出的数据。 趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的逻辑关系想明白。这才是性能测试分析中最重要的一环。 最后才是调优：有了第3步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果 性能分析思路 瓶颈的精准判断 对性能瓶颈做出判断是性能分析的第一步，有了问题才能分析调优。 TPS曲线 很多人在描述性能测试的过程中，说要找到性能测试中曲线上的“拐点
网站性能测试基本指标
热门推荐
大鹏
05-12 4万+
一．系统吞度量要素：   一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。 单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间         QPS（TPS）：每秒钟request/事务 数量         并发数： 
性能测试瓶颈分析
03-23
确定哪部分功能是性能的瓶颈，分析windowresource图表，查看cpu 　使用下列计数器标识cpu瓶颈 　Processor\Interrupts/sec 　Processor\%ProcessorTime 　Process(process)\%ProcessorTime 　System\Processor
性能测试技巧，性能瓶颈分析，性能调优
06-08
本文将深入探讨几个关键概念和技术，包括TPS、QPS、吞吐量、性能测试流程和策略，以及性能瓶颈分析与调优。 1. TPS（Transactions Per Second）和QPS（Queries Per Second） TPS是衡量系统每秒处理事务的数量，而...
性能测试知多少---吞吐量
虫师
02-21 1488
我们每天的生活中都在用水用电，我只会关心自己的水管是否有水，水压是否稳定，如果我们把水龙头拧到最大，还是一滴一滴的流水。那我们就要愤怒了，直接找房东问明情况。我们从来没想过去找自来水公司。我们每天都会上网，网速很慢，看个电影很卡，需要等很久才缓冲一个画面，我们打开网页很慢，IE状态条一直50%，那我们就要愤怒了，直接找电信、网通公司问明情况。 　　我想说以上的情况是正常的，如果你在优酷上看视频，
JUC-如何选择线程数量
子悠のziyou
11-11 935
即使有上面的简单估算方法，也许看似合理，但实际上也未必合理，都需要结合系统真实情况（比如是IO密集型或者是CPU密集型或者是纯内存操作）和硬件环境（CPU、内存、硬盘读写速度、网络状况等）来不断尝试达到一个符合实际的合理估算值。
【速看】一招教你快速如何快速确定线程池的线程数
唐欢
09-15 1437
线程池标准创建方式是通过标准构造器ThreadPoolExecutor去构造工作线程池。那么corePoolSize和maximumPoolSize 的该如何设置呢？在设置这两个值之前，首先需要通过任务类型对线程池进行分类， 可以分为IO密集型任务，CPU 密集型任务和混合型任务。
性能测试问题排查一例——网络带宽瓶颈
lin的专栏
01-17 1万+
近期在做一个项目的性能测试时，在打压时发现压力达到100hps后就一直打不上去，同时还会报读redis服务器超时的错误。查看了下打压服务器的cpu和内存占用，没有发现什么异常。 Cpu占用： 内存占用： 1、由于会报redis链接超时错误，首先定位到的是redis服务器挂了，找到开发将log中添加具体连接超时的redis服务器ip信息后，重新跑了一
前端nginx带宽占用高排除思路
白衣不染尘的博客
08-14 1608
前端nginx带宽占用高排除思路 排除步骤 查看哪个进程占用流量高 nethogs 查看哪个外网ip连接占用流量高 iftop 抓包对应的外网ip tcpdump 将异常ip封禁iptables 1、nethogs 安装： apt-get installnethogs -y yum installnethogs -y 2、if...
性能分析(一)
ths512的博客
08-04 4269
一、图表分析 1.Average Transaction Response Time(事务平均响应时间) “事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向，例如随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着时间的变化，整体性能将会有下降的趋势 2.运行Vuser-----事务平均响应时...
性能分析
YiLi_world的博客
04-09 189
JProfiler使用详细教程学习笔记(https://www.cnblogs.com/langtianya/p/3172180.html) Java性能分析神器-JProfiler详解（一）(https://www.cnblogs.com/AmilyWilly/p/7272160.html)
性能瓶颈分析及案例总结
03-04
"该文档是关于性能瓶颈分析的总结，主要涵盖了如何进行性能测试和分析，包括了多个实际操作步骤和使用工具的介绍，适用于系统管理员、开发人员和性能测试工程师，以帮助他们识别和解决系统性能问题。文档强调了性能...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值