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

概述

性能测试中,对服务端的指标监控也是很重要的一个环节。通过对各项服务器性能指标的监控分析,可以定位到性能瓶颈。

后端性能指标有CPU,内存,网络,I/O等等

分析思路

  • 整体系统CPU利用率
  • 内存利用率
  • 磁盘I/O的利用率和延迟
  • 网络利用率

CPU定位分析

CPU利用率大于50%,需要注意;大于70%,需要密切关注;高于90%,情况比较严重。

监控命令:vmstat、sar、dstat、mpstat、top、ps

类型 度量方法 衡量标准
利用率
1、vmstat 统计1-%idle

2、sar -u 统计1-%idle

3、dstat 统计1-%idl

4、mpstat -P ALL 统计1-%idle

注意>=50%

告警>=70%

严重>=90%

满载

1、vmstat的r值> cpu逻辑颗数

2、sar -q ,“runq-sz”>cpu逻辑颗数

 运行队列大于1时,证明已经有一定的负载

内存定位分析

当物理内存不够时,会使用swap分区,所以性能测试过程中需要关注swap和mem的使用情况。

物理内存不够,大量的内存置换到swap空间,可能导致CPU和I/O的瓶颈。

监控命令:vmstat、sar、dstat、free、top、ps等

类型
度量方法


衡量标注

占用率
1、free 查看使用情况

2、vmstat

3、sar -r

4、ps


注意>=50%

告警>=70%

严重>=80%

满载
1、vmstat的si/so比例,swapd占比

2、sar -W 查看次缺页数

3、dmesg | grep killed


1、so数值大,且swapd已经占比很高,内存已经饱和

2、sar命令次缺页多意味内存已经饱和

3、内存不够用会触发内核的OOM机制

网络定位分析

监控命令:sar、ifconfig、netstat,以及查看net的dev速率。

通过查看发现收发包的吞吐率达到网卡的最大上限,网络数据报文有因为这类原因而引起的丢包、阻塞等现象都证明当前网络可能存在瓶颈。

为了减小网络对性能测试的影响,一般我们都在局域网中进行测试执行。

类型 度量方法 衡量标准
使用情况
1、sar -n DEV 的收发计数大于网卡上限

2、ifconfig RX/TX宽带超过网卡上限

3、cat /proc/net/dev的速率超过上限

4、nicstat的util基本满负荷


1、收发包的吞吐率达到网卡上限

2、有延迟

3、有丢包

4、有阻塞

满载
1、ifconfig dropped 有计数

2、netstat -s "segments retransmited"有计数

3、sar -n EDEV,rxdrop/s  txdrop/s有计数

有丢包统计
错误
1、ifconfig,“errors”

2、netstat -i,RX-ERR TX-ERR

3、sar -n EDEV,rxerr/s   txerr/s

4、ip -s link, “errors”

错误有计数   

IO定位分析

I/O读写频繁的时候,如果I/O得不到满足会导致应用的阻塞。

需要考虑I/O的TPS、平均I/O数据、平均队列长度、平均服务时间、平均等待时间、IO利用率(磁盘Busy Time%)等指标

监控命令:sar、iostat、iotop

类型 度量方法 衡量标准
使用情况
1、iostat -xz,“%util”

2、sar -d,“%util”

3、cat /proc/pid/sched | grep iowait


注意>=40%

告警>=60%

严重>=80%

满载
1、iostat -xnz,“avgqu-sz ”>1

2、iostat await>70

IO疑似满载
错误
1、dmseg 查看io错误

2、smartctl /dev/sda

有错误信息

原文地址:https://www.cnblogs.com/Zfc-Cjk/p/11262924.html

时间: 2024-11-03 03:26:42

性能测试-服务端瓶颈分析思路的相关文章

rpc的几种服务端模型分析

rpc(Remote Procedure Call)是一种通过网络从远程计算机程序上请求服务而不用了解细节的协议.通常client端为服务的调用方,server端为服务的提供方.他们之间可以在不同的网络.不同的机器,使用不同的语言. server端作为一个网络的服务提供者,需要能为多个client端提供高质量的服务,如下总结了几种服务端的模型.     (一)单线程模型 一个线程顺序处理所有请求. 优:简单 缺:同一时刻只能处理一个连接请求     (二)多线程模型(短连接) 一个线程处理一个请

TYPESDK 服务端设计思路与架构之六:性能及调优初步

经过本系列前几篇文字的分析和设计,我们成功地开发出了自己的SDK服务端.在我们自己的调试环境下运行一切正常,但是当然我们不能就这样把这套SDK服务端部署上线到正式生产环境,稍有正式大型项目经验的同学应该都知道性能优化以及部署上线相关设计对于服务端项目的重要性.我们到目前为止的分析设计中,并没有考虑到这些设计.那么,针对我们SDK服务端这样的应用场景,应该着重关注哪些相关的优化和设计呢? 数据存取优化 在我们的应用场景中,需要使用到存储的场景主要在以下几个处理中: l  获取配置信息 对每个收到的

asp.net 简单记录请求的客户端和服务端 处理时间

最近项目需要简单记录一下 ajax客户端和服务端处理时间,服务端时间的思路是借用BeginRequest和EndRequest事件,为了不影响现有接口返回的数据格式,因此服务处理时间放在response 的header里面. BeginRequest += (sender, args) => { HttpContext.Current.Items["ServerStartTime"] = DateTime.Now.Ticks.ToString(); }; EndRequest +

rtsp实时流通过rtmp推送到服务端

很多朋友都会问到rtsp如何通过rtmp协议推送到服务端,正好前段时间开发了这个功能写在这里,和大家分享下. 首先我想说的是:ffmpeg可以实现这个功能.ffmpeg支持rtsp协议,也支持rtmp.在这个案例中rtsp是输入, rtmp是输出,ffmpeg实现了转码的功能.下面可出一个整体思路流程图. 图1 如图1所示:在获取都rtsp流以后,解复用(demux)获取ES流packet,最后将ES流封装成rtmp格式并发送 到服务端. 基本思路完毕,下面上代码. 一:初始化ffmpeg库 v

用http请求thrift服务端出现了内存溢出的情况

记一次内存溢出的分析经历 - Janti - 博客园 https://www.cnblogs.com/superfj/p/8474288.html 说在前面的话 朋友,你经历过部署好的服务突然内存溢出吗? 你经历过没有看过Java虚拟机,来解决内存溢出的痛苦吗? 你经历过一个BUG,百思不得其解,头发一根一根脱落的烦恼吗? 我知道,你有过! 但是我还是要来说说我的故事.................. 背景: 有一个项目做一个系统,分客户端和服务端,客户端用c++写的,用来收集信息然后传给服务

TYPESDK手游聚合SDK服务端设计思路与架构之一:应用场景分析

TYPESDK 服务端设计思路与架构之一:应用场景分析 作为一个渠道SDK统一接入框架,TYPESDK从一开始,所面对的需求场景就是多款游戏,通过一个统一的SDK服务端,能够同时接入几十个甚至几百个各种渠道的SDK.而且这些渠道接口的具体接入字段和接入逻辑,每个月以至每周,都可能发生或大或小的变动.在这样一个复杂的应用场景下,我们应该如何设计一个足够强大而又足够灵活的SDK服务端呢? 首先我们需要厘清,在整个应用场景中,TYPESDK所处的位置,以及它所需要实现的核心功能. 图1 如图1所示,T

性能测试常见瓶颈分析及调优方法

在性能测试过程中,最重要的一部分就是性能瓶颈定位与调优.而引发性能瓶颈的原因是多种多样的,在之前的博客:常见的性能测试缺陷有进行介绍. 这篇博客,来聊聊性能测试过程中的一些注意事项,以及常见的一些性能缺陷表现及如何进行定位分析并且调优... 一.注意事项 1.断言 在压测时,为了判断发送的请求是否成功,一般会通过对请求添加断言来实现.使用断言时,建议遵循如下规范: ①.断言内容尽量以status/code.msg/message来判断(当然前提是接口设计遵循Restful规范) Jmeter示例

运维经验分享(四)--关于 java进程管理的服务控制脚本编程思路分析

运维经验分享作为一个专题,目前共7篇文章 <运维经验分享(一)-- Linux Shell之ChatterServer服务控制脚本> <运维经验分享(二)-- Linux Shell之ChatterServer服务控制脚本二次优化> <运维经验分享(三)-- 解决Ubuntu下crontab不能正确执行Shell脚本的问题(一)> <运维经验分享(四)--关于 java进程管理的服务控制脚本编程思路分析> <运维经验分享(五)-- 改进的java进程管

Redis源码分析(三十四)--- redis.h服务端的实现分析(1)

上次刚刚分析过了客户端的结构体分析,思路比较简答,清晰,最后学习的是服务端的实现,服务端在Redis可是重中之重,里面基本上囊括了之前模块中涉及到的所有知识点,从redis的头文件就可以看出了,redis.h代码量就已经破1000+行了,而且都还只是一些变量,宏定义的声明,和一些方法原型的声明.所以,今天的总结跟昨天一样,先不做具体的实现学习,先从全局的角度思考,服务端的整体设计思路,这从头文件的声明正好可以学习. /* ----------------------- 声明了一下所需的头文件,主