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

jmeter 压测时设置了内存为sed -i 's/HEAP="-Xms512m -Xmx512m"/HEAP="-Xms36096m -Xmx360096m"/' jmeter占了48G内存中的很大一部分再执行的时候会出现如下提示:Cannot allocate memory Creating summariser <summary>Created the tree successfully using multiple.jmxStarting the

在做dubbo的jmeter压测时,需要把jar包放入jmeter的lib/ext目录下,但是jmeter启动的时候会自动加载这个目录lib目录及lib/ext目录,这样启动后放入这些目录下的jar包就不会加载了. jmeter的master--slave/client模式下,作为jmeter client,jmeter-server服务一直是启动的,当新的jar包放入client后,无法读取,因此需要client的jmeter动态加载这些新放入的jar包. 解决办法参考:http://blog

前言 使用jmeter 做压测的时候,希望对一个接口持续压测 10 分钟或者半小时,可以使用调度器设置持续压测时间. 设置样本总数 压测方式有2种,一种是设置线程组和循环次数,这样可以设置一个样本总数,完成固定次数的请求后结束. 比如我线程组设置5,循环次数为10,那么总样本数就是5*10=50 查看聚合报告,样本数是固定的50,达到50个后会结束 调度器 通过控制总的请求次数,我们没法控制结束时间,有时候领导要求压测10分钟或者半小时,怎么办? 第二种压测方式,使用调度器设置持续时间,控制压测

[问题]Error -10776  Failed to find .cfg file 错误分析:在loadrunner打开脚本的情况下,运行磁盘清理工具,导致运行打开的脚本时,提示Mdrv error:Failed to find .cfg file MsgId:MERR-10777解决方法:从其它文件夹拷贝3个文件到不能正常运行脚本的文件夹下:default.cfgdefault.usp*.prm(将*的位置改为脚本的名字)再次运行脚本,可以正常运行 [问题] Error -13874: mi

1.top 命令查看占用cpu高的进程,pid=15019 2.查看该进程下所有占用cppu高的线程 top -Hp pid   即:top -Hp 15019 得到pid 3.获取15030的16进制 print "%x\n" 15030 3ab6 4.jstack -l 15019 > ~/jvm_stack_log.log 5.日志中查询 cat jvm_stack_log.log |grep 3ab6 ------------ 大部分线程都是在进行GC操作 解决办法: t

1.新建测试计划,在测试计划里勾选“独立运行每个线程组” 2.分别在每个线程组,添加聚合报告,以得到每个线程组的压测结果 3.设置不同接口压测的vu等,并为每个线程组,设置合理的启动延迟时间

今天压力测试时, 刚开始出现了很多异常, 都是 java.net.NoRouteToHostException: Cannot assign requested address. 经网上查资料, 是由于linux分配的客户端连接端口用尽, 无法建立socket连接所致,虽然socket正常关闭,但是端口不是立即释放, 而是处于TIME_WAIT状态, 默认等待60s后才释放. 查看linux支持的客户端连接端口范围, 也就是28232个端口: cat /proc/sys/net/ipv4/ip_

一.环境: 服务器:linux 4核 16G 虚拟机 1台 客户端:linux 4核 16G 2000台(模拟) 数据包大小:1036字节 二.参数设置: ulimit -n 65536 服务端处理线程2,端口4440 客户端数据包大小:约1k 三.应答模式测试 3.1 测试 模拟2000客户端并发访问,每个客户端与服务端交互10次总共花费的时间,单位是毫秒 3.2 结果 平均:24149.5ms 每条线程平均耗时:12.07475ms 单个任务平均:1.207475ms 客户端数量[个] 单个

在BAT这种大厂里,只要肯吃苦,技术和工资进步的速度会超出你想象,我在上海,按当前价格算,一般在大厂里干个三四年,好歹房子的首付应该能有,而且这种房子还不是太偏远太小的. 进大厂确实需要一定的实力,但如果单单技术好,没有其它的技巧,估计确实也有些难度.不过话说来,哪怕是二本出身,哪怕技术一般,只要肯上心加方法得当,工作后3年进大厂应该不是难事.在本文里,就将针对起点一般技术一般的同学,给出具体的进大厂操作指南. 一.先从战略上藐视,进大厂也就这回事 大厂里也有只有2,3年开发经验的初级开发,而且

上一篇文章找同事review了一下,收到的反馈是铺垫太长了,我尽量直入正题,哈哈 最近dbd压测时发现内存泄漏,其实这个问题去年已经暴露了,参见这篇博客[压测周].当时排查不够仔细,在此检讨下.关于dbd的内存问题,还有这篇博客讨论线程安全,以及这篇博客讨论临时变量的处理.当时还存了一个尾巴,因为用到关联数组进行脏数据管理,这部分数据是怎么释放的一直没搞明白.今天算是搞明白了,这个内存泄漏的bug也源于此. 基于引用计数的gc机制,应该是在引用计数为0的时候释放内存的,lpc也基本没有例外.具体

不久前参与开发了一个基于dubbo分布式框架的底层账单系统,并实现了其中的一部分业务接口,目前需对这些接口进行压测,以评估生产环境所能承受的最大吞吐量.笔者以其中一个查询接口为例来回顾此次压测的整体流程. 压测准备: 1.调用查询接口的测试jar包,作为dubbo-consumer,依赖了查询服务的api,测试module基于maven开发,执行maven clean package即可通过编译得到jar包 2.JMeter:Apache组织开发的基于Java的压力测试工具 方案: 无限次请求查

压测之四两拨千斤核心观念: 1.传统的http请求肯定不能用于压测,原因是请求一次,响应一次,而响应数据同时占用了客户端的带宽,故此,客户端请求后,不需要接受响应,让服务器单相思去. 2.寻找可以令服务器产生内存或带宽(包括网络带宽/IO带宽等)负载的接口进行压测 何为压测,何为DDOS攻击.CC攻击,我想,百度会告诉你一切. 在做这件事情之前,我先贴上一份代码,如果你是测试工程师,或许这份代码对你有用. package com.ezone.test.socket;import java.net

单台压测机通常会遇到客户端瓶颈,受制于客户机的性能.可能由于网络带宽,CPU,内存的限制不能给到服务器足够的压力,这个时候你就需要用到分布式方案来解决客户机的瓶颈,压测的结果也会更加接近于真实情况. jdk和jmeter的下载和安装就不说了 jmeter 分布式压测原理: 分布式压测分为两块: 控制器(controller)和代理(agent) controller 负责把脚本分发给 agent执行. agent 负责执行脚本,产生对服务器的实际压力,agent 不需要运行 jmeter,运行 

Linux 性能监控之CPU&内存&I/O监控Shell脚本2   by:授客 QQ:1033553122 思路: 捕获数据->停止捕获数据->提取数据 备注:一些命令的输出,第一次记录的数据是自重启到当前时间的平均值,所以,如果采用循环的方式不断重复开启命令,获取的数据可能不太准确,所以,这里采用开启命令后,一次性捕获需要的数据. (一) 捕获数据 用法:sh capture.sh arg1 arg2 参数说明:arg1为采样频率,arg2为采样时长,单位都为秒 例子:2秒采

背景 小米容器云平台,在构建云厂商集群时,需要通过HAProxy将云厂商LB流量从宿主机转到容器中,但对于HAProxy的性能没有把握.参考网上的一篇HAProxy压测文章,文章中提到HAProxy establish状态连接可以达到 400w,所以以此为目标,进行压测. 参考文章:文章地址 关键点 TCP计数器ListenOverflows大量增加 查看方法 cat /proc/net/netstat | awk '/TcpExt/ { print $21,$22 }' 原因 系统调用list

一.业务背景+系统架构 本次场景为kafka+storm+redis+hbase,通过kafka的数据,进入storm的spout组件接收,转由storm的Bolt节点进行业务逻辑处理,最后再推送进kafka. 表数据相关的逻辑为:查询Hbase表数据,首次查询会写入redis和storm cache,再次查询,会直接从redis或cache中取值. storm应用: 二.性能测试场景 1.数据:json类型的用户偏好数据700万 2.灌入方式:java脚本 3.hbase表:生产全量数据导入

背景 在美团的价值观中,以“客户为中心”被放在一个非常重要的位置,所以我们对服务出现故障越来越不能容忍.特别是目前公司业务正在高速增长阶段,每一次故障对公司来说都是一笔非常不小的损失.而整个IT基础设施非常复杂,包括网络.服务器.操作系统以及应用层面都可能出现问题.在这种背景下,我们必须对服务进行一次全方位的“体检”,从而来保障美团多个业务服务的稳定性,提供优质的用户服务体验.真正通过以下技术手段,来帮助大家吃的更好,生活更好: 验证峰值流量下服务的稳定性和伸缩性. 验证新上线功能的稳定性. 进

目录 sysbench压测-innodb_deadlock_detect参数对性能的影响 一.OLTP测试前准备 二.进行OLTP测试 三.测试结果解读: 四.关于测试后的结论: 五.关于测试后的性能优化: 1.善后清理工作: 2.运行优化建议工具 3.修改mysql参数 4.再次启动测试流程 sysbench压测-innodb_deadlock_detect参数对性能的影响 一.OLTP测试前准备 基本信息: 主机信息 CPU 内存 硬盘 系统版本 MySQL版本 sysbench版本 Int

line: V1.3 mail: gczheng@139.com date: 2017-11-09 一.TPCC测试前准备 1.压测环境 配置 信息 主机 Dell PowerEdge R730xd CPU 24xIntel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz 内存 64G(16G * 4) RAID卡 LSI Logic MegaRAID SAS 系统 "Red Hat Enterprise Linux Server release 7.3 (Maipo)&

版权声明:本文为博主原创文章,转载请注明出处. 记一次压测时Java内存泄漏问题的发现过程(2017-08-14) [前篇] ①20170811进行A系统与B系统之间的会话功能进行压测,加上脚本准备期间的聊天消息,预计累计聊天30w+条消息: ②20170814原计划加大量对会话功能进行压测,情况如下: [应用表现] ①B系统前台打开报错“504”: ②查看后台应用CPU情况,CPU利用率高达700+%(8核): ③查看后台内存情况,持续FullGC,且一次FullGC的时长在9s左右,从这里可