性能瓶颈分析思路

性能瓶颈分析思路

性能分析是一个大课题,不同的架构、不同的应用场景、不同的程序语言分析的方法各有差异,抽象一下大致分为二类:

自底向上:通过监控硬件及操作系统性能指标(CPU、内存、磁盘、网络等硬件资源的性能指标)来分析性能问题(配置、程序等的问题)。因为用户请求最终是由计算机硬件设备来完成的,做事的是 CPU。

自顶向下:通过生成负载来观察被测试的系统性能,比如响应时间、吞吐量;然后从请求起点由外及里一层一层的分析,从而找到性能问题所在。

不管是自底向上还是自顶向下,关键点就是生成负载、监控性能指标。上面我们说了两种方法,大家会问哪一种方法更好呢?哪种方法更简单一点呢?我想说的是方法无所谓好坏,只是一个思路。

对于没有经验的性能测试工作者,提倡自底向上;对于经验丰富的性能测试工作者,先用自顶向下的方式解决掉明显性能问题,再接合自底向上的方式分析更深层次的问题。

 性能分析流程

从性能测试工程师的角度来讲解一下通常的性能分析过程(操作系统以Linux为例)。


序号


步骤名称


说明


1.0


检查RT


模拟用户发起负载后,采用自顶向下的方式首先分析RT(响应时间)。

1.如果RT小,TPS大,说明性能良好。

2.如果RT小,TPS小,检查负载机资源占用情况,确定是否要加大负载。

3.如果RT大,TPS小,检查负载机的资源消耗,确保不是负载机的性能原因导致的RT变大。


1.1


检查TPS


1.TPS大时RT小,说明性能良好

2.TPS小时RT大,检查负载机的资源消耗,确保不是负载机的性能原因导致的RT变大。


2.0


检查负载机资源消耗耗


1.检查CPU使用率,CPU负载(LoadAverage)确认是用户CPU占用高还是系统CPU占用高?确认测试脚本没有性能问题,不会造成结

果统计的不准确

2.检查内存使用情况,确认并发内存泄露风险,不会造成结果统计的不准确。

3.检查网络占用带宽。大家可以做个小实验,一台并发100用户,一台运行一个用户,比较两者的响应时间是否在同一个数量级,从而评估负载机对性能的影响。


2.1


判下负载机是否有性能问题


排除负载机的性能问题,确保测试结果可参考。


3.0


检查Web 服务器的资源消耗


1.检查CPU使用率,确认用户CPU与系统CPU占用情况

1.1系统CPU占用多,检查系统调用情况,找出是哪个进程或线程,确认调用是否正常?比如滥写日志,导致系统CPU利用率高。

1.2用户CPU高,找出进程或线程,定位到程序,确认是否调用正常?一般来说Web服务程序不涉及到运算的,CPU利用率高要确认是否是其它资源等待导致的CPU利用率高。

1.2.1比如IO等待会带来CPU利用率高,CPU由于等待IO,而频繁的进行上下文切换。

1.2.2比如事务过程较长,需要锁定的资源较多,而请求也较多时,CPU需要不停的中断、上下文切换去处理获取到资源的请求。

2.检查内存使用情况,找出占内存多的进程或线程

3.检查磁盘使用情况,找出IO量大的进程或线程

4.检查占用的带宽

5.分析Web页面响应的时间组成


3.1


确认是否

Web服务器瓶颈


从3.0监控指标判断是否是Web服务器硬件性能瓶颈。


3.2


检查中间

件配置


1.检查中间件线程池活动连接数,确认是否是此配置问题。

2.检查Heap配置,确认gc的影响。


3.3


是否是中间件限制


1.监控线程池活动连接数,确认线程池够用。

2.监控线程状态,如果长期是Blocked状态,可能是响应慢,有可能会导致死锁,Dump线程栈找到疑问程序。

3.监控JVM,关注GC,评估Heap空间是否够用。


4.0


检查APP 服务器资源消耗


分析方法同3.0。


4.1


确认是否

App服务器瓶颈


从3.0监控指标判断是否是App服务器硬件性能瓶颈


4.2


检查中间

件配置


1.检查中间件线程池。

2.检查数据库连接池。

3.检查Heap配置。


4.3


是否是中间件限制


1.监控线程池,确认线程池够用。

2.监控线程状态,如果长期是Blocked状态,代表响应慢,有可能会导致死锁。

3.监控与数据库的连接数,确认数据库连接池是否够用。

4.监控JVM,关注GC,评估Heap空间是否够用。可以借助JVisualVM、

Jprofiler来分析,也可以使用Jdk自带的监控命令。


5.0


数据库服务器资源消耗分析


1.CPU消耗,CPU负载。

2.内存消耗。

3.IO繁忙程度。

4.数据库监控

4.1慢查询。

4.2对DB不熟悉的读者可以找DBA帮忙监控分析。


5.1


是否是DB

性能问题


由5.0的监控结果来判断是否是DB性能问题。

 linux主机瓶颈阀值分析

CPU定位分析


模块


类型


度量方法


衡量标准


CPU


使 用

情况

  1. 通过vmstat 统计1-id 的计数
  2. 通过top统计1-id的计数

注意>=50% 告警>=70% 严重>=90%


CPU


满载

  1. vmstat 的r计数 > CPU逻辑颗数
  2. top, "load average" > CPU逻辑颗数

运行的队列大于cpu逻辑颗数时,证明已经有一定的负载了,不过这个计数也不绝对,需进一步分析其他的资源情况来断定是否

CPU已经满负荷运作

我们可以用的命令有vmstat, top ,sar,dstat, mpstat, ps 等命令来进行统计分析。

vmstat 字段含义说明:


类别


项目


含义


说明


Procs(进程)


r


等待执行的任务数


展示了正在执行和等待cpu资源的任务个数。当这个值超过了cpu个数,就会出现cpu瓶颈。


B


等待IO的进程数量


Memory(内存)


swpd


正在使用虚拟的内存大小,单位k


free


空闲内存大小


buff


已用的buff大小,对块设备的读写进行缓冲


cache


已用的cache大小,文件系统的cache


Swap


si


每秒从交换区写入内存的大小(单位:kb/s)


so


每秒从内存写到交换区的大小


IO


bi


每秒读取的块数(读磁盘)


现在的Linux版本块的大小为1024bytes


bo


每秒写入的块数(写磁盘)


system


in


每秒中断数,包括时钟中断


这两个值越大,会看到由内核消耗的cpu时间会越多


cs


每秒上下文切换数


CPU(以百分比表示)


Us


用户进程执行消耗cpu时间(user time)


us的值比较高时,说明用户进程消耗的cpu时间多,但是如果长期超过50%的使用,那么我们就该考虑优化程序算法或其他措施了


Sy


系统进程消耗cpu时间(system time)


sys的值过高时,说明系统内核消耗的cpu资源多,这个不是良性的表现,我们应该检查原因。


Id


空闲时间(包括IO等待时间)


wa


等待IO时间


Wa过高时,说明io等待比较严重,这可能是由于磁盘大量随机访问造成的,也有可能是磁盘的带宽出现瓶颈。

内存定位分析


模块


类型


度量方法


衡量标准


内存


使用情况

  1. free命令查看使用情况
  2. vmstat命令查看使用情况

注意>=50% 告警>=70% 严重>=80%


内存


满载

  1. vmstat 的 si/so 比例辅助 swapd和free利用
  2. sar –W 查看次缺页数
  3. 查看内核日志有无 OOM 机制 kill进程
  4. dmesg | grep killed

OOM机制

我们可以用的命令有 vmstat,sar,dstat, free, top , ps 等命令来进行统计分析。

free 字段含义说明:


参数

释义
total 内存总数,物理内存总数
used 已经使用的内存数
free 空闲的内存数
shared 多个进程共享的内存总额
buffers/cache 缓存内存数
available 可用内存数
Swap 交换分区,虚拟内存

网络定位分析


模块


类型


度量方法


衡量标准


网络


使用情况

  1. ifstat 的收发计数大于网卡上限
  2. iftop RX/TX带宽超过网卡上限
  3. nicstat的 util 基本满负荷
 

网络


满载

  1. ifconfig dropped 有计数
  2. netstat      –s     "segments retransmited"有计数

统计的丢包有计数证明已经满了


网络


错误

  1. ifconfig, "errors"
  2. netstat -i, "RX-ERR"/"TX-ERR"

错误有计数

衡量系统网络的使用情况,我们可以使用的命令有ifstat,iftop,netstat以及查看net的速率,通过查看发现收发包的吞吐速率达到网卡的最大上限,网络数据报文有因为这类原因而引发的丢包

阻塞等都证明当前网络可能存在瓶颈。在进行性能测试时为了减小网络的影响,一般我们都是在局域网中进行测试执行。

nicstat命令详解

磁盘IO定位分析


模块


类型


度量方法


衡量标准


IO


使用情况

  1. iostat –xz , "%util"
  2. iotop 的利用率很高

注意>=40% 告警>=60% 严重>=80%


IO


满载

  1. iostat   -xnz 1,   "avgqu-sz" >1
  2. iostat   await >   70

IO 已经有满载嫌疑


IO


错误

  1. dmesg 查看io 错误
  2. smartctl /dev/sda

有信息

衡量系统IO的使用情况,我们可以使用的命令有sar, iostat,iotop等命令进行系统级的IO监控分析。当发现IO的利用率大于40%时候,就需要注意了,当使用率大于60%则处于告警阶段,大于80%IO就会出现阻塞了。

iostat -x命令详解


选项

说明
rrqm/s 每秒对该设备的读请求被合并次数,文件系统会对读取同块(block)的请求进行合并
wrqm/s 每秒对该设备的写请求被合并次数
r/s 每秒完成的读次数
w/s 每秒完成的写次数
rkB/s 每秒读数据量(kB为单位)
wkB/s 每秒写数据量(kB为单位)
avgrq-sz 平均每次IO操作的数据量(扇区数为单位)
avgqu-sz 平均等待处理的IO请求队列长度
await 平均每次IO请求等待时间(包括等待时间和处理时间,毫秒为单位)
svctm 平均每次IO请求的处理时间(毫秒为单位)
%util 采用周期内用于IO操作的时间比率,即IO队列非空的时间比率

tomcat 性能监控和分析

连接器(Connector)的参数配置

  • HTTP/1.1:默认值,使用的协议与Tomcat版本有关
  • org.apache.coyote.http11.Http11Protocol:BIO
  • org.apache.coyote.http11.Http11NioProtocol:NIO
  • org.apache.coyote.http11.Http11Nio2Protocol:NIO2
  • org.apache.coyote.http11.Http11AprProtocol:APR

Attribute

描述

maxConnections

服务器在任何给定时间接受和处理的最大连接数。当达到这个数字时,服务器将接受一个进一步的连接,但不会处理。这个附加连接将被阻塞,直到正在处理的连接数降到maxConnections以下,服务器再次开始接受并重新处理新的连接。
acceptCount 所有可能的请求处理线程正在使用时,传入连接请求的最大队列长度。 当队列满时收到的任何请求都将被拒绝。 默认值为100。
connectionTimeout 连接器在接受连接后等待的请求URI行的毫秒数。 使用值-1表示无(即无穷大)超时。 默认值为60000(即60秒),但请注意Tomcat附带的标准server.xml将其设置为20000(即20秒)。 除非disableUploadTimeout设置为false,否则读取请求主体(如果有的话)也将使用此超时。
keepAliveTimeout 连接器在关闭连接之前等待另一个HTTP请求的毫秒数。 默认值是使用为connectionTimeout属性设置的值。 使用值-1表示无(即无穷大)超时。
maxKeepAliveRequests 在服务器关闭连接之前可以进行流水线处理的最大HTTP请求数。将此属性设置为1将禁用HTTP / 1.0保持活动状态,以及HTTP / 1.1保持活动状态和流水线状态。将其设置为-1将允许无限量的流水线或保持活动的HTTP请求。如果未指定,则此属性设置为100。
executor 对Executor元素中的名称的引用。 如果设置了此属性,并且命名的执行程序存在,则连接器将使用执行程序,并且所有其他线程属性将被忽略。 请注意,如果未为连接器指定共享执行程序,则连接器将使用专用的内部执行程序来提供线程池。

线程池Executor的参数配置

  • name:该线程池的标记
  • maxThreads:线程池中最大活跃线程数,默认值200(Tomcat7和8都是)
  • minSpareThreads:线程池中保持的最小线程数,最小值是25
  • maxIdleTime:线程空闲的最大时间,当空闲超过该值时关闭线程(除非线程数小于minSpareThreads),单位是ms,默认值60000(1分钟)
  • daemon:是否后台线程,默认值true
  • threadPriority:线程优先级,默认值5
  • namePrefix:线程名字的前缀,线程池中线程名字为:namePrefix+线程编号

tomcat监控

对tomcat的监控主要就是查看服务器中的连接数和线程数,以及线程状态的监控

查看大致分为两种方案:(1)使用现成的工具,(2)直接使用Linux的命令查看。

命令方式:

查看线程数

ps -Lf 163610 |wc -l

查看连接数

netstat -nat|awk ‘{print $6}‘|sort|uniq -c|sort

工具监控:tomcat manager,JProfiler,JConsole,jvisualvm, Btrace等

下图是tomcat manager监控页面

线程问题

1、Deadlock问题必须要解决,

2、大量线程处于Blocked状态 waiting状态

3、线程不够用

4、线程占用资源高需要分析

命令行分析资源消耗最高的线程

实例讲解

下面已本次支付性能测试的一个性能问题为实例来讲解整个分析过程

1、通过查看tps和响应时间,确认存在性能瓶颈

2,检查日志,发现有错误日志,首先解决错误日志问题,但是性能问题依旧未解决

3、监控服务进程资源,发现cpu利用率为200%多,内存, IO都无瓶颈

4、监控可以看出时间都消耗在tss服务内部,考虑通过线程分析是否有阻塞导致,通过命令jstack打印线程堆栈信息

jstack -l PID >tmp.txt

原文地址:https://www.cnblogs.com/wsy0202/p/12104058.html

时间: 2024-10-01 07:10:27

性能瓶颈分析思路的相关文章

服务器性能瓶颈分析思路

参考: http://itindex.net/detail/53357-%E7%90%86%E8%A7%A3-linux-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F http://ixdba.blog.51cto.com/2895551/715742

性能测试-服务端瓶颈分析思路

概述 性能测试中,对服务端的指标监控也是很重要的一个环节.通过对各项服务器性能指标的监控分析,可以定位到性能瓶颈. 后端性能指标有CPU,内存,网络,I/O等等 分析思路 整体系统CPU利用率 内存利用率 磁盘I/O的利用率和延迟 网络利用率 CPU定位分析 CPU利用率大于50%,需要注意:大于70%,需要密切关注:高于90%,情况比较严重. 监控命令:vmstat.sar.dstat.mpstat.top.ps 类型 度量方法 衡量标准 利用率 1.vmstat 统计1-%idle 2.sa

mysql性能瓶颈分析、性能指标、指标搜集方法与性能分析调优工具

本文主要讲解mysql的性能瓶颈分析.性能指标.性能指标信息的搜集工具与方法.分析调优工具的使用. 文章尚未完成. 性能瓶颈: 慢.写速度比读速度慢很多  主要的性能指标: 访问频度, 并发连接量, 缓存命中率, index使用, slow log开启与分析, query Log,查询log Threads_cached:连接线程缓存是否开启  -> ONthread_cache_size :线程缓存数的大小query_cache_size: 查询缓存大小join_buffer_size :jo

多线程_java多线程环境下栈信息分析思路

导读:Java多线程开发给程序带来好处的同时,由于多线程程序导致的问题也越来越多,而且对问题的查找和分析解决对于菜鸟程序原来是是件头疼的事.下面我就项目中使用多线程开发程序过程中遇到的问题做详细的分析和解决思路的分享.本人也属菜鸟,忘大神指点. 项目描述: 工作中要编写一份程序用于爬取某某网站上的大量图片.从HBase里面遍历出所有的爬取任务,开启固定大小的线程池Executors.newFixedThreadPool(100),提交线程,线程每个线程做的事情是使用FileUtils.copyU

CPU利用率异常的分析思路和方法交流探讨

CPU利用率异常的分析思路和方法交流探讨在生产运行当中,经常会遇到CPU利用率异常或者不符合预期的情况,此时,往往暗示着系统性能问题.那么究竟是核心应用的问题?是监控工具的问题?还是系统.硬件.网络层面的问题?在上线前的测试过程中,经常会遇到新版本应用的CPU占用率比旧版本高,那么到底是新增的或者变更的什么模块导致呢?面对这种情况,我们应该如何定位和诊断问题的根本原因? 本期专题讨论会分享采用什么样的分析思路.分析方法和分析工具进行CPU使用情况的分析:并帮助大家解答以下问题: 1. CPU利用

第一次OllyDbg逆向记录(分析思路和注意点&其他文章)

OllyDbg 操作菜单栏.工具栏.快捷键 C++调用加强 目录 OllyDbg 操作菜单栏.工具栏.快捷键    1 一.    载入观察    1 1.静态载入观察:    1 2.OD动态观察    1 二.    初步尝试下断查找目标    1 1.如何下断    1 2.接下来有两个选择:    1 2.1手动F9运行目标    1 2.2设条件断点    1 2.3 CALL调用时堆栈小解    1 3.初步断点目标 (条件触发情况)    1 三.调用栈回溯    1 1.回溯到无

性能测试通用分析思路和报告编写技巧

1. 通用分析思路 观察现象-->层层递进-->缩小范围-->推理分析-->不断验证-->确定结论 观察现象:现象只要是指页面的表现.服务器的资源表现.各类中间件的健康度.log日志. 各类软件的参数.各类数据库的健康度等. 需要关注的公共指标:响应时间.TPS.QPS.成功率.CPU.MEMORY.IO.连接数.进程\线程数.缓存命中率.流量等: 除了公共指标外,还有一些针对具体系统软件需要监控的指标.比如,JVM中各内存代的回收情况以及GC的情况,PHP-FPM中的max

通过 Java 线程堆栈进行性能瓶颈分析

改善性能意味着用更少的资源做更多的事情.为了利用并发来提高系统性能,我们需要更有效的利用现有的处理器资源,这意味着我们期望使 CPU 尽可能出于忙碌状态(当然,并不是让 CPU 周期出于应付无用计算,而是让 CPU 做有用的事情而忙).如果程序受限于当前的 CPU 计算能力,那么我们通过增加更多的处理器或者通过集群就能提高总的性能.总的来说,性能提高,需要且仅需要解决当前的受限资源,当前受限资源可能是: CPU: 如果当前 CPU 已经能够接近 100% 的利用率,并且代码业务逻辑无法再简化,那

ANR 分析思路浅析

一.引言 ANR问题是android中常见且令人头疼的问题,相当多的时候不易直接分析出原因. 二.ANR的定义   下面先看下百度百科给ANR的定义: ANR问题常因在main(主线程)线程执行了复杂耗时的操作,比如文件IO.网络访问.无限循环等,最终无奈地被系统抛出ANR. 三.ANR的一般分析思路 1) 从手机的/data/traces/目录导出traces.txt文件: 2) 从traces.txt文件获取ANR产生的时间点T1: 3) 从traces.txt文件获取main线程的运行状态