压测过程中网络带宽瓶颈案例分析

近期在做一个项目的性能测试时,在打压时发现压力达到100hps后就一直打不上去,同时还会报读redis服务器超时的错误。

查看了下打压服务器的cpu和内存占用,没有发现什么异常。

通过nmon监控服务器资源信息

CPU占用:

内存占用:

1、由于会报redis链接超时错误,首先定位到的是redis服务器挂了,找到开发将log中添加具体连接超时的redis服务器ip信息后,重新跑了一遍。

依然会报连接redis服务器超时错误,开发立即查看了下对应ip的redis服务器。发现运行情况没有出现任何问题,各项指标均正常

2、查看压力服务器的各项指标来定位问题。

用sar命令看了下磁盘性能,发现每秒写扇区的次数达到300以上,怀疑是写入次数过多导致的,于是查了下开发的脚本,发现开发每一步判断逻辑中都加了写errorlog操作。于是怀疑是写log导致的。

将开发的写log操作大部分都关闭(除了读redis服务器错误)后,重新跑了一下,发现写扇区的次数降到100左右,但是tps依然打不上去。排除了磁盘写入的问题。

3、接下来安装了nmon工具后,重新跑了一遍,看了下网络传输,发现tps达到100左右时,网络出口占用为120M/s!这是千兆网卡的满载速率了。于是定位到网络成为主要的瓶颈。

网络I/O传输表:可以发现eth0-write的速率达到120千KB,也就是120M(注意这里的单位是“千”)

4、查了下自己的打压脚本,发现部分请求的返回数据大小为4M。果断将请求的返回改为200K后重新打压后,压力可以成功达到2000hps以上。同时也没有再出现读redis超时的错误。

至此,此次问题排查圆满结束。同时向大家着力推荐一下nmon工具。里面记录的参数很全,基本上定位性能的指标(比如cpu、内存、每个cpu、每个磁盘分区的读写、磁盘busy情况、网络吞吐、网络包数据等)都能够统计到。

时间: 2024-10-11 14:21:08

压测过程中网络带宽瓶颈案例分析的相关文章

压测过程中使用nmon对服务器资源的监控

1.nmon工具的下载和安装: 官网:http://nmon.sourceforge.net/pmwiki.php 下载完成后进行解压,更改权限:chmod 777 2.查看linux系统的版本,再使用对应版本的nmon: [[email protected] ~]# cat /etc/*release CentOS release 6.6 (Final) LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noa

压测过程中,CPU和内存占用率很高,案例简单分析

Q:  最近公司测试一个接口,数据库采用Mongo    并发策略:并发400个用户,每3秒加载5个用户,持续运行30分钟    数据量:8000条左右 压测结果发现:    TPS始终在5左右    而CPU高达99%,内存使用情况也高达1.7G    网卡流量145K 请问这种情况,是哪里的性能出现问题? A:你这个CPU和内存监控的得是web服务器 就是部署程序的机器.    1.尝试查看出现这类情况时候数据库process,看看是否是当时进程到达了所设置的进程数上限.如果是则调整数据库进

在压测过程中,jmeter跑一段时间以后卡死的解决方案

Jmeter在跑压测的时候,本来设置了10分钟,但是跑到5分钟的时候就卡死了,再关了以后重新跑还是这样(图1),于是各种百度,最后解决方案如下: 右击点击编辑,记事本打开(图2) 修改后的(图3) set HEAP=-Xms256m -Xmx1024m set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m 再重启jmeter,压测的时候就不会报错了: 注意:压测的时候禁用查看结果树!

tomcat7+java压测过程中占用CPU过高排查故障和解决办法

环架构境: 前端haproxy做为反向代理,后端N+1台tomcat+java服务 出现问题: 环境是新搭建的,本周在做压测刚开始的时候正常,随着量的上涨,导致CPU一直暴涨. 解决办法和思路: 1.)先通过top命令查看占用cpu高的PID # 根据top命令查看发现PID为2195和975的的进程占用CPU高达%200+,明显出现故障 2.)通过top -H -p pid命令查看,发现2275 3302 3375这几个进程占用CPU时间8分钟 3.)把线程pid转换为16进制,例如:上面的p

性能测试:Jmeter压测过程中的短信验证码读取

问题背景 现如今国内的大部分软件或者网站应用,普遍流行使用短信业务,比如登录.注册以及特定的业务通知等. 对于这些业务,在使用Jmeter进行性能测试的过程中,就会需要自动获取和填入短信验证码,否则性能流程无法进行下去. 由于绝大多数的系统其短信验证码并不会在接口返回中,因此如何获取短信验证码是一个问题. 最简单的做法,是让开发在测试环境将验证码写死,在测试过程中固定使用静态验证码字串. 不过求人不如求己~也是出于尽量贴近真实用户场景的目的,更合适的做法还是通过技术手段动态获取并填写短信验证码.

压测过程中故障排查之一:高CPU占用问题分析案例

说明: 一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环 以我们最近出现的一个实际故障为例,介绍怎么定位和解决这类问题. 根据top命令,发现PID为28555的Java进程占用CPU高达200%,出现故障. 通过ps aux | grep PID命令,可以进一步确定是tomcat进程出现了问题.但是,怎么定位到具体线程或者代码呢? 首先显示线程列表: ps -mp pid -o THREAD,tid,time 找到了耗时最高的线程28802,占用CPU时间快两个小

关于s5pv210的配置、编译过程中相关文件的分析(Makefile、config.mk、mkconfig)

uboot为用户提供两种编译方式,一种是在uboot当前目录下进行编译,第二种方式就是将编译生成的文件输出到指定的目录下. 1) Add O= to the make command line # 'make O=/tmp/build all' # # 2) Set environement variable BUILD_DIR to point to the desired location # 'export BUILD_DIR=/tmp/build' # 'make' # # The se

【接口】接口压测性能分析及调优建议

常见的互联网架构中,一般都能看到spring+mybatis+mysql+redis搭配的身影,在我所服务的公司亦是如此.一般来说,应用内部的接口都是直接调用的,所谓的面向接口编程,应用间的调用直接调或者通过类似dubbo之类的服务框架来执行,数据格式往往采用json,即统一也方便各数据间做转换和取值,缓存一般使用redis或memcached,存储一些对象或json格式的字符串.对外提供的接口,一般都需要进行压力测试,以便估算其性能,并为后续的调优提供指导方向,以下接口便是在压测过程中出现的各

后端服务性能压测实践

转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 排查周边依赖 空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 关注各纬度 log Linux 常规命令 性能排查两种方式(从上往下.从下往上) 总结 背景 最近大半年内有过两次负责性能压测的一些工作.一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题