我在下面的命令中使用了netperf benchmark:
服务器端:netserver -v -d -N -p
客户端:netperf -H -p -l 60 -T 1,1 -T TCP_RR
我收到了结果:
将TCP REQUEST/RESPONSE TEST从0.0.0.0(0.0.0.0)端口0 AF_INET迁移到10.0.0.28()端口0 AF_INET: demo: first burst 0: cpu bind
本地/远程
套接字大小请求响应。经过反式。Send Recv Size Size时间速率
bytes bytes bytes bytes secs。每一秒
16384 131072 1 1 60.00 9147.83
131072
但是当我通过添加&;maxcpus=1 nr_cpus=1&;将客户端更改为单CPU(同一机器)时到内核命令行。然后我运行下一个命令:
netperf -H -p -l 60 -t TCP_RR
我收到了下一个结果:
将TCP REQUEST/RESPONSE TEST从0.0.0.0(0.0.0.0)端口0 AF_INET迁移到10.0.0.28()端口0 AF_INET: demo: first burst 0: cpu bind
本地/远程
套接字大小请求响应。经过反式。Send Recv Size Size时间速率
bytes bytes bytes bytes secs。每一秒
16384 131072
Q:我不明白当我把CPU数量从64个减少到1个时，性能是如何提高的?
一些技术信息:我使用Azure的Standard_L64s_v3实例类型;操作系统:sles: 15: sp2
•您在客户端执行的' netperf '实用程序命令如下，在更改客户端cpu数量后是相同的，但是您可以看到在减少客户端虚拟机上vcpu数量后性能有所提高:-
netperf -H -p -l 60 -I 1,1 -t TCP_RR
上面的命令意味着你想要测试主机' Server '和' Client '之间的TCP请求/响应的网络连接性能，并在默认目录路径中获得结果，该路径将在60秒内创建管道。
•CPU利用率测量机制在Linux操作系统上使用' proc/stat '来记录这些命令执行所花费的时间。此机制的代码可以在' src/netcpu_procstat.c '中找到。。因此，您可以相应地检查配置文件。
此外，虚拟客户机环境(即虚拟机)中的CPU利用率机制可能无法像裸机环境那样反映实际利用率，因为大部分网络处理都发生在虚拟机的上下文中。。因此，按照下面惠普的文档链接:-https://hewlettpackard.github.io/netperf/doc/netperf.html
如果想要测量虚拟化机制增加的开销，而不是依赖CPU利用率，可以使用netperf _RR测试——路径长度和开销可能是延迟的很大一部分，因此开销的增加应该随着事务速率的降低而出现。无论你做什么，都不要依赖_STREAM测试的吞吐量。实现链接率可以通过多种选项来实现，这些选项可以掩盖开销，而不是消除它。
因此，我建议您依赖Azure中可用的其他监控工具，即Azure Monitor, Application insights等。
仔细查看netperf命令行:
netperf -H -p -l 60 -T 1,1 -T TCP_RR
-H选项期望将主机名作为参数。而-p选项期望将端口号作为参数。正如所写的"将被解释为主机名。当我尝试的时候，至少会失败。我猜您省略了一些命令行?
-T选项将绑定netperf和netserver将在哪里运行(在本例中，在netperf端的vCPU 1和netserver端的vCPU 1上)，但它不一定控制至少一些网络堆栈处理将在哪里发生。因此，在64-vCPU设置中，网络流量和堆栈的中断将在不同的vCPU上运行。在1-vCPU设置中，所有内容都在一个vCPU上。可以想象，在64-vCPU的情况下，缓存到缓存传输的效果会降低事务/秒速率。
使用多处理器将提高聚合性能，但不一定会提高单线程/流性能。单线程/流的性能确实会下降。