虚拟网卡性能压测

本文主要介绍多种场景下,虚拟机网卡的压测及性能对比,根据openstack实际的部署方式,虚拟机网卡压测场景包括 SRIOV(passthrough)、SRIOV+Macvtap(passthrough)、Vlan+Linux bridge、OVS+Linux Bridge,分别从协议类型(TCP/UDP)、Message Size方向压测虚拟机网卡的时延、发包率、吞吐量。

压测环境

host1:  服务器型号:IBM x3550m2

CPU型号:Intel(R) Xeon(R) CPU*8,每个CPU有4核,共32核

内存大小:32GB

硬盘大小:SAS 500G*2

网卡:Intel 82576 Gigabit (Driver:igb)

host2:  服务器型号:IBM x3550m2

CPU型号:Intel(R) Xeon(R) CPU*8,每个CPU有4核,共32核

内存大小:32GB

硬盘大小:SAS 500G*2

网卡:Intel 82576 Gigabit (Drvier:igb)

vm1:   vcpu:1

内存大小:1GB

硬盘大小:sda : 40GB

IP:  192.168.20.101/24 (Driver:igbvf/virtio_net)

虚拟机网卡压测

在开发环境下压测虚拟机网卡,连接宿主机的端口设置成Trunk,仅允许指定Vlan的数据通过,以至无法直接压测宿主机的物理网卡。为了保证压测正常进行,进出宿主机物理网卡的数据都打上tag(SRIOV指定VF的vlan,Linux bridge连接vlan子接口,OVS设置port的tag)。本次使用netperf工具压测,宿主机host1内创建虚拟机vm1,宿主机host2与vm1互发送数据进行压测,运行python脚本使虚拟机vm1的CPU状态接近饱满, 同时关闭host1、host2、vm1的iptables。

延时

虚机CPU处于非饱满状态下压测网卡延时,host1使用netperf 向 vm1发送数据(TCP/UDP),netperf 命令行:netperf -H 192.168.20.101 -t omni -- -d rr -T UDP -O "THROUGHPUT, THROUGHPUT_UNITS, MIN_LATENCY, MAX_LATENCY, MEAN_LATENCY"  ,如下图所示

压测结果发现同场景下虚拟网卡对不同Message Size的延时差别并不大(可能是因为宿主机直接连到同一台switch), 汇总多次延时的压测结果如下:

发包率

虚机CPU处于非饱满状态下压测网卡延时,host1启动150个netserver, vm1同时启动150个netperf进程向host1发数据,直达vm1的CPU饱满状态。运行netperf命令行:netperf -t TCP_RR  -H 192.168.20.101 -l 60 -p 12856 -- -r 64 64 (请求/应答报文为64Bytes), 汇总多次延时的压测结果如下:

吞吐量

原计划用工具netio压测吞吐量,netio压测吞吐量时vm1的CPU处于非饱满状态,最后选择netperf以多线程脚本向vm1打数据(发包率基础上计算对应Message size的吞吐量)。

注:

1.压测的虚机网卡driver是 virtio_net,与openstack创建的虚机保持一致,virtio_net的性能远高于配默认的8139cp。

2.pktgen工具不能压测SRIOV(ptkgen发包时不能绑定到VF,因为pktgen是从内核直接发包,会造成dst_mac的最后一个字节与VF生成的网卡关联,如VF对应eth5则dst_mac则会变为xx:xx:xx:xx:xx:e5)。

3.引起延时的因素比较多:本地主机与服务器路由跳数,网络带宽,处理带宽。netperf测延时的结果明显比ping的延时低。

后记

从上面的压测数据得出:

1.SRIOV性能高于其它场景

2.SRIOV+Macvtap性能高于Vlan+Linux bridge、OVS+Linux bridge

3.Vlan+Linux bridge性能高于OVS+Linux bridge

但是SRIOV也有局限性如特定型号网卡支持、千兆网卡只支持7个VF、不支持迁移。SRIOV+Macvtap可解决热迁移的问题,相对于Vlan+Linux bridge和OVS+Linux bridge有性能有提升,openstack用SRIOV+Macvtap解决SRIOV热迁移的BP还没有实现,Vlan+Linux bridge性能稍高于OVS+Linux bridge。对虚拟机网卡的性能要求特别高同时不考虑迁移,用SRIOV比较合适。对网络管理要求比较高(gre,vxlan),只能用OVS+Linux bridge。

压测工具

本次压测尝试了多个压测工具netperf、iperf、netio、pktgen,它们对比情况如下表:

参考链接:

http://filwmm1314.blog.163.com/blog/static/2182591920130309833682/

http://blog.163.com/hlz_2599/blog/static/142378474201341341339314/

http://blog.csdn.net/kozazyh/article/details/4939694

https://www.kernel.org/doc/Documentation/networking/pktgen.txt

http://mp.weixin.qq.com/s?__biz=MzAxOTAzMDEwMA==&mid=402362721&idx=1&sn=4b729bd3678af519aeb174571bdc2d8e&scene=23&srcid=1202K1QgMANMuRjQLwqvZOoV#rd

时间: 2024-10-09 22:37:39

虚拟网卡性能压测的相关文章

性能压测诡异的Requests/second 响应刺尖问题

最近一段时间都在忙着转java项目最后的冲刺,前期的coding翻代码.debug.fixbug都逐渐收尾,进入上线前的性能压测. 虽然不是大促前的性能压测要求,但是为了安全起见,需要摸个底心里有个数. 毕竟这次转java的服务都是集团核心公共服务(主要是订单域服务).(等我们顺利上线了,我再来好好总结下其中的坎坷和壮举.) 废话不多说了,直接进入主题. 由于这次压测主要重点是关注正向的两个核心订单服务,下单服务.查单服务.查单服务初步压测下来问题不大,主要是db的索引和cache的问题. 下单

感受真实性能压测的“洪荒之力” 压测宝有奖体验中

作为测试,你有没有遇到这样的问题:1.熬了多少个日夜的系统终于快上线了,不知道上线后系统负载能力怎样?2.促销季到了,应用性能如何?到底能不能支持500w并发用户?3.怎么做压测才能更接近线上真实环境? 系统负载有多强,压测一下就知道.云智慧压测宝3步6分钟 开启真实用户的性能压测 8月16至9月2日申请试用压测宝,感受真实压测的洪荒之力,还有机会获得优酷视频会员卡,速速来领- 参与活动赢优酷会员卡 1.从这里申请试用压测宝:[url=http://yacebao.com/landingPage

swingbench-免费的oracle性能压测工具

SwingBench介绍: SwingBench由负载生成器,协调器和集群概述组成.该软件使得能够生成负载并且将图表的事务/响应时间映射. SwingBench可用于演示和测试诸如实际应用集群,在线表重建,备用数据库,在线备份和恢复等技术 SwingBench附带的代码包括6个基准,OrderEntry,SalesHistory,TPC-DS Like,JSON,CallingCircle和StressTest .. OrderEntry基于Oracle11g / Oracle12c附带的"oe

接口测试及服务器性能压测

目前移动端app大都还是采用的http或者https协议写的restful接口,一般的辅助类http劫持(fiddler,charles)和模拟发送(postman)工具都可以满足单次单个接口的测试需求,但这种依附工具的测试很难满足多接口调用逻辑验证问题,也不太灵活,没办法做到数据化,还有就是对于接口压测和服务器性能压力测试无法满足,又得借助于其他压测工具(Jmeter loadrunner等),设计一套基于http和https灵活定制的接口测试框架还是很有必要的. 一般app接口调用都要都要传

后端服务性能压测实践

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

(转)后端服务性能压测实践

作者:王清培(Plen wang) 传送门:https://www.cnblogs.com/wangiqngpei557/p/7953453.html ---------------------------------------------------------------------分割线------------------------------------------------------ 入职新公司,没人理我,负责的需求开发一直很忙,要么环境有问题,要么Bug卡住我找开发,回了一句

RocketMQ性能压测分析(转)

原创文章,转载请注明出处:http://jameswxx.iteye.com/blog/2093785 一   机器部署 1.1  机器组成 1台nameserver 1台broker  异步刷盘 2台producer 2台consumer 1.2  硬件配置 CPU  两颗x86_64cpu,每颗cpu12核,共24核 内存 48G 网卡 千兆网卡 磁盘 除broker机器的磁盘是RAID10,共1.1T,其他都是普通磁盘约500G 1.3  部署结构 橙色箭头为数据流向,黑色连接线为网络连接

RocketMQ性能压测分析(转载)

一   机器部署 1.1  机器组成 1台nameserver 1台broker  异步刷盘 2台producer 2台consumer 1.2  硬件配置 CPU  两颗x86_64cpu,每颗cpu12核,共24核 内存 48G 网卡 千兆网卡 磁盘 除broker机器的磁盘是RAID10,共1.1T,其他都是普通磁盘约500G 1.3  部署结构 橙色箭头为数据流向,黑色连接线为网络连接 1.4  内核参数 broker是一个存储型的系统,针对磁盘读写有自己的刷盘策略,大量使用文件内存映射

SSDB性能压测报告

测试场景 机器: 两台Intel(R) Xeon(R) E5506  2.13GHz  (4核 8线程)*2/内存32GB/SAS 300G 数据: key: 10位顺序数字     value: 50字节      数据量: 2kw 并发: 并发数依次为10.20.40.80.160 压测工具:redis-benchmark ssdb 版本: 1.9.2 ssdb 配置: leveldb: cache_size: 5120 block_size: 32 write_buffer_size: 6