之前分享过kvm性能优化方案,http://blog.csdn.net/beginning1126/article/details/41983547这篇文章,今天将在实验室测试的测试用例和测试结果分析一并贡献出来,有这方面研究的同学可以参考一下。
用例名称 | 测试步骤 | 期待结果 | 实测结果 | 备注 |
并发测试用例1 | 在单台host上分别起1台vm,8核cpu,在vm上部署tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发量:185.55 响应时间:5.389ms 运算量最大值:107 |
|
并发测试用例2 | 在单台host上分别起1台vm,8核cpu,将8核cpu绑定到不同的node上,在vm上部署tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发量:154.30 响应时间:6.481ms 运算量最大值:64 |
|
并发测试用例2 | 在单台host上分别起1台vm,8核cpu,将8核cpu绑定到同一个node上的不同core上,在vm上部署tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发量:200.20 响应时间:4.995ms 运算量最大值:108 |
|
并发测试用例2 | 在单台host上分别起1台vm,8核cpu,将8核cpu绑定到同一个node的同一个core上,在vm上部署tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发量:142.99 响应时间:6.993ms 运算量最大值:55 |
|
并发测试用例3 | 在单台host上分别起1台vm,16核cpu,在vm上部署tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发量:379.83 响应时间:2.633ms |
|
并发测试用例4 | 在单台host上分别起1台vm,32核cpu,在vm上部署tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发量:544.07 响应时间:1.838ms |
|
并发测试用例5 | 在物理机(32核cpu)上部署tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发:573.93 响应时间:1.742ms |
|
并发测试用例6 | 在单台host上分别起2台vm,8核cpu,在vm上部署nginx+tomcat作为webserver,用Apache ab命令跑并发,大文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发:343.21 响应时间:2.914ms |
|
并发测试用例7 | 在单台host上分别起2台vm,16核cpu,在vm上部署nginx+tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发:518.93 响应时间:1.927ms |
|
并发测试用例8 | 在单台host上分别起4台vm,32核cpu,在vm上部署nginx+tomcat作为webserver,用Apache ab命令跑并发,小文件 | 物理机:tps,平均响应时间,最大响应时间,最小响应时间,吞吐量等,JVM使用情况,系统负载等 | 并发:545.61 响应时间:1.833ms |
|
cpu测试 | 1、在32核host上跑测试脚本 2、不做cpu spin,在32核vm上跑测试脚本 3、将vcpu和物理cpu一一绑定,在32核vm上跑测试脚本 |
最大矩阵计算量 | host计算量:249 vm计算量:189 CPU的频率为2.4GHz 理论计算值:2.4*8*16=307, 1、host:249/307=81%, 2、VM:189/307=61.6% 3、vm:235/307=76.5% |
|
cpu测试 | 在1台8核vm上跑测试脚本 1、不做cpu spin操作 2、将cpu spin到同一个node的不同core上 3、将cpu spin到不同node上 4、将cpu spin到同一个node的同一个core上 |
最大矩阵计算量 | 计算量分别为: 1、107 2、108 3、64 4、55 |
|
cpu测试 | 在host上起4台8核vm,分别同时跑脚本 1、不做cpu spin操作 2、将cpu spin到同一个node的不同core上 3、将cpu spin到同一个node上的同一个core上 |
最大矩阵计算量 | 1、57.2118+63.7892+56.9805+57.9403=235.9218(76.8%) 2、61.5600+58.0845+61.9926+59.6644=241.3015(78.6%) 3、54.0601+54.7793+54.2481+54.9129=218.0004(71%) |
|
内存测试 | 1、在32核host上跑测试脚本 2、不做cpu spin,在32核vm上跑测试脚本 3、将vcpu和物理cpu一一绑定,在32核vm上跑测试脚本 |
1、带宽 2、延时 |
1、host: Function Best Rate MB/s Avg time Min time Max time Copy: 44052.5 0.748480 0.726406 0.791428 Scale: 44504.5 0.736819 0.719028 0.800202 Add: 50850.5 0.974595 0.943944 1.023264 Triad: 50580.2 0.974862 0.948987 1.040257 2、vm: Function Best Rate MB/s Avg time Min time Max time Copy: 27394.2 0.268220 0.233626 0.295008 Scale: 26209.4 0.270150 0.244187 0.300134 Add: 31089.2 0.353235 0.308789 0.386995 Triad: 31144.0 0.348140 0.308246 0.397927 3、vm: Function Best Rate MB/s Avg time Min time Max time Copy: 44293.7 0.164213 0.144490 0.388600 Scale: 44437.7 0.163192 0.144022 0.297840 Add: 50450.9 0.202506 0.190284 0.304565 Triad: 50610.0 0.197781 0.189655 0.264187 |
|
内存测试 | 关闭透明大页,仅对虚拟机操作 echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag |
1、带宽 2、延时 |
Function Best Rate MB/s Avg time Min time Max time Copy: 23595.0 0.281552 0.271244 0.301159 Scale: 24072.6 0.283809 0.265863 0.328187 Add: 26914.4 0.372515 0.356686 0.393995 Triad: 27528.2 0.373740 0.348734 0.428311 |
|
内存测试 | 打开透明大页、打开碎片整理 echo always > /sys/kernel/mm/transparent_hugepage/enabled echo always > /sys/kernel/mm/transparent_hugepage/defrag |
1、带宽 2、延时 |
Function Best Rate MB/s Avg time Min time Max time Copy: 24895.3 0.279777 0.257077 0.325637 Scale: 25382.4 0.274935 0.252143 0.293212 Add: 28597.6 0.366685 0.335692 0.414622 Triad: 29185.1 0.358809 0.328935 0.381043 |
|
内存测试 | 打开透明大页、关闭碎片整理 echo always > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag |
1、带宽 2、延时 |
Function Best Rate MB/s Avg time Min time Max time Copy: 27394.2 0.268220 0.233626 0.295008 Scale: 26209.4 0.270150 0.244187 0.300134 Add: 31089.2 0.353235 0.308789 0.386995 Triad: 31144.0 0.348140 0.308246 0.397927 |
|
磁盘测试 | 针对磁盘测试 1、针对host磁盘跑fio,分别得出随机读写、顺序读写的iops 2、针对vm磁盘跑fio,cache mode=none,block size=4K,分别得出随机读写、顺序读写的iops 3、针对vm磁盘跑fio,cache mode=writeback,block size=4K,分别得出随机读写、顺序读写的iops |
1、iops | 1、host, block size=4K randwrite=1208 randread==2513 write=112390.5 read=111688 2、vm, cache mode=none, block size=4K randwrite=1664 randread=16172 write=50117 read=36755 2、vm, cache mode=writeback, block size=4K randwrite=16024 randread=51831 write=45745 read=51500 |
|
磁盘测试 | 针对文件系统测试 1、针对host文件系统跑fio,分别得出随机读写、顺序读写的iops 2、针对vm文件系统跑fio,cache mode=none,block size=4K,分别得出随机读写、顺序读写的iops 3、针对vm磁盘跑fio,cache mode=writeback,block size=4K,分别得出随机读写、顺序读写的iops |
1、iops | 1、host, block size=4K randwrite=789 randread=1146 write=35879.4 read=26886 2、vm, cache mode=none, block size=4K, openstack randwrite=898.6 randread=1958 write=9269.8 read=9846 3、vm, cache mode=writeback,block size=4K, openstack randwrite=1165.3 randread=247708.3 write=10643.3 read=69276 |
当cache mode=writeback时 1、cpu,user+sys始终处于20~40的负载,wait不稳定0~40忽高忽低。 2、流量也不稳定,有时几百兆的流量,有时为0。 writeback模式,在其qemu和host kernel都有数据cache,会有大量的数据拷贝,所以会占用cpu,,并且由于cache的存在导致流量也不稳定,并且通过测试数据来看,其写iops未有太大的提升,读能力会有显著提升,可能是由于fio读取的数据重复性比较高,所以cache命中的几率会大些 |
磁盘测试 | qcow2和raw对比测试 1、通过openstack创建vm,镜像格式为raw,cache mode=none,block size=4K,分别得出随机读写、顺序读写的iops 2、通过openstack创建vm,镜像格式为qcow2,cache mode=none,block size=4K,分别得出随机读写、顺序读写的iops |
1、iops | 1、vm, cache mode=none, block size=4k, openstack raw randwrite=775 randread=2840 write=35909 read=26526 2、vm, cache mode=none, block size=4k, openstack qcow2 randwrite=1276 randread=1958 write=9745 read=8700 |
通过qcow2和raw的对比发现,两种随机写iops差不多,raw顺序读写性能和host差不多,而qcow2顺序读写能力都比较差,而其随机读能力比较强 |
磁盘测试 | qcow2多vm测试,vm, cache mode=none, block size=4k, openstack qcow2 1、10台vm,同时测试随机write性能 2、10台vm,同时测试随机read性能 3、10台vm,同时测试顺序write性能 4、10台vm,同时测试顺序read性能 |
1、iops | 1、16+20+66+18+13+18+21+19+16+411=618 2、45+47+731+680+35+49+224+36+44+38=1929 3、3965+3996+3978+4054+4030+2871+2940+2951+2884+2748=34417 4、2111+2113+1350+1335+1392+1393+1576+2483+2408+1517=17678 |
|
网络测试 | 1、在两个host上分别起9台vm,两端host上的vm用iperf对跑流量 2、在两端host上跑iperf,7对 |
1、吞吐量 | 1、25MB+16MB+37MB+27MB+15MB+19MB+48MB+24MB+15MB=227MB 2、230MB |
|
网络测试 | 1、host,nginx做web server,ab命令跑并发 2、vm,fixed ip,nginx做web server,ab命令跑并发 3、vm,floating ip,nginx做web server,ab命令跑并发 |
1、并发量 | 1、host 并发:10832.1 2、vm 并发:8634.2 3、vm 并发:8496.2 |
|
网络测试 | 1、host,用qperf测试带宽和延时 2、vm,fixed ip,用qperf测试带宽和延时 3、vm,floating ip,用qperf测试带宽和延时 |
1、带宽 2、延时 |
1、 tcp_bw: bw = 117 MB/sec tcp_lat: latency = 60.46 us 2、 tcp_bw: bw = 117 MB/sec tcp_lat: latency = 100.7 us 3、 tcp_bw: bw = 114 MB/sec tcp_lat: latency = 105.53 us |
|
网络测试 | 1、host间,用qperf测试带宽和延时(百兆网卡) 2、同一个vlan fixed ip,用qperf测试带宽和延时(千兆网卡) 3、同一个vlan floating ip,用qperf测试带宽和延时(百兆网卡) 4、不同vlan floating ip,用qperf测试带宽和延时(百兆网卡) |
1、带宽 2、延时 |
1、 tcp_bw: bw = 11.7 MB/sec tcp_lat: latency = 125 us 2、 tcp_bw: bw = 116 MB/sec tcp_lat: latency = 162 us 3、 tcp_bw: bw = 11.7 MB/sec tcp_lat: latency = 186.4 us 4、 tcp_bw: bw = 11.7 MB/sec tcp_lat: latency = 187.5 us |
对于vlan环境host需要2个网卡,floating ip之间 通信通过eth1(百兆网卡),fixed ip通信通过eth0(千兆网卡),所以fixed ip吞吐量大一些 |
测试过程:在单台host上起一台vm,8核cpu,cpu采用不同的绑定策略。在vm上部署tomcat作为web server,用apache ab命令跑并发,并将8核cpu全部跑满,测试文件为动态小文件,得出并发量、响应时间。通过大量的矩阵运算,得出cpu运算量
分析不同绑定策略对8核cpu vm的影响如何。
序号 |
cpu绑定策略 |
并发量 |
运算量 |
响应时间(ms) |
1 |
kvm默认 |
185.55 |
107 |
5.389 |
2 |
将8核cpu绑定到不同的node上 |
154.3 |
64 |
6.481 |
3 |
将8核cpu绑定到同一个node上的不同core上 |
200.2 |
108 |
4.995 |
4 |
将8核cpu绑定到同一个node的同一个core上 |
142.99 |
55 |
6.993 |
分析:从测试结果来看,绑到同一个node的不同core上其cpu性能是最好的。同一个node上会共享l3 cache,而一个core上的两个超线程,是虚拟出来的2个cpu,存在竞争关系,所以绑到同一个core上,性能反而会下降。
结论:将cpu帮到同一node的不同core上,性能最优。
测试过程:在单台host上分别启用不同数量不同核数的vm,并通过cpu pinning技术优化cpu性能。在vm或host上部署tomcat作为web server,用apache ab命令跑并发,并将cpu全部跑满,测试文件为动态小文件,得出并发量、响应时间。通过大量的矩阵运算,得出cpu运算量
序号 |
测试环境 |
并发量 |
响应时间(ms) |
Cpu运算量 |
1 |
1台32核host |
573.93 |
1.742 |
249 |
2 |
1台32核vm |
544.07 |
1.838 |
235 |
3 |
2台16核vm |
518.93 |
1.927 |
|
4 |
4台32核vm |
545.61 |
1.833 |
|
分析:hostcpu频率为2.4G Hz,理论计算值为2.4*8*16=307,host计算效率为249/307=81%,32核vm计算效率为235/307=76.5%,相差大约4.5%。并发量相差大约5.2%,响应时间相差大约5.2%
结论:通过cpu pinning技术,优化后的vm cpu性能和host相比,大约会有5.2%的损耗。
测试过程:分别在32核host和32核vm上内存性能测试,vm上打开透明大页和关闭内存碎片整理,测试内容为数组的拷贝、加法、乘法、加法和乘法结合,得出内存带宽。
序号 |
测试环境 |
Copy(MB/s) |
Scale(MB/s) |
Add(MB/s) |
Triad(MB/s) |
1 |
1台32核host |
44052.5 |
44504.5 |
50850.5 |
50580.2 |
2 |
1台32核vm |
44293.7 |
44437.7 |
50450.9 |
50610.0 |
分析:测出的内存带宽是瞬时值,所以上下会有些波动,从测试数据来看,host和vm内存性能不相上下。
结论:vm内存性能几乎没有损耗。
测试过程:分别在host、vm(镜像格式分别为raw和qcow2)和单台host上的10台vm(镜像格式为qcow2)跑iops,得出randwrite、randread、write、read的iops。Vm磁盘优化策略包括virtio、缓存模式=none、aio=native、块设备调度策略=Deadline。
序号 |
测试环境 |
Randwrite |
Randread |
Write |
Read |
1 |
Host |
789 |
1146 |
35879.4 |
26886 |
2 |
Vm raw |
775 |
2840 |
35909 |
26526 |
3 |
Vm qcow2 |
898.6 |
1958 |
9269.8 |
9846 |
4 |
10台vm qcow2 |
618 |
1929 |
34417 |
17678 |
分析:镜像格式为raw的vm,其性能和host性能几乎没有差别。镜像格式为qcow2的vm,其随机读写性能和host相比略好(由于qemu有cache缓存,所以iops相对会高些),但是顺序读写性能很差。如果单台host上的10台vm同时操作fio,得出iops的和,顺序读写性能会有很大程度的提升。而且这也比较符合实际云计算应用场景。
raw镜像虽说性能很好,但是不具备伸缩和快照功能,虚机的创建和迁移都要花费大量时间,不适用于线上实际云环境的使用。建议采用qcow2。
结论:采用qcow2作为磁盘镜像格式,随机读写性能和host相比差别不大,顺序写损耗4%,顺序读损耗34.2%
测试过程:通过qperf测试host和vm(包括fixed ip和floating ip)带宽和延时,在host和vm上部署nginx做web server,10k的静态文件,用apache ab命令跑并发,得出并发量。网络优化策略包括virtio和vhost。
序号 |
测试环境 |
吞吐量(MB/sec) |
延时(us) |
并发量 |
1 |
Host |
117 |
60.46 |
10832 |
2 |
Vm fixed ip |
117 |
100.7 |
8634.2 |
3 |
Vm floating ip |
114 |
105.53 |
8496.2 |
分析:吞吐量基本没有损耗,vm fixed ip会增加40us的延时,vmfloating ip会增加45us的延时,由于floating比fixed多了个nat转换,性能会略有损耗。
结论:吞吐量基本没有损耗,延时增加40~45us,其中nat会增加5us延时,后续会继续尝试SR-IOV进行延时优化。
原文地址:http://blog.csdn.net/beginning1126/article/details/46121239