2024年5月1日发(作者：亢俊材)
网卡革命―华为iNIC1000智能网卡评
测报告
因为工作的原因,我们经常在服务器上利用开源软件搭建一些测试环境,用
以考察新软件或硬件平台的实际性能。长期的测试让我们注意到,无论是单路、
双路还是四路平台,只要CPU核数超过两个,对I/O密集型应用的性能提升也只
是微乎其微。更有甚者,双路平台下某些应用的性能竟不及单路平台,显然有违
常理。 也并不是只有网络通信和安全方面的应用才算I/O密集型应
用。经常关注实验室评测报告的读者朋友们应该注意到,我们已经很久不用静态
页面脚本测试服务器性能了。甚至ASP、环境下负载较轻的脚本,测得
性能也只列为参考。这是因为,失败的HTTP请求总是过早地出现,此时CPU占用
率却并不高。而以往的经验(包括世界实验室评测标准中的规定)是,只有当处理
器整体利用率达到100%才会出现错误,这个临界值就是服务器针对当前脚本的
最大处理能力。 前段时间,我们特别针对这个问题进行了研究,希望找到真
正的原因。测试平台是一台配备了双路英特尔至强5472(3.0GHz,共 8核)、
5000P芯片组、8GB FB-DIMM、双口英特尔82575EB网络控制器的服务器,操作
系统采用了64位Red Hat Enterprise Linux 5.1,与多数商业用户目前实际使
用的配置相仿。2.6.18版的Linux内核也能很好地支持我们选用的硬件平台,
系统安装完毕即可开始使用。Kernel的配置文件表明,内核已开启NAPI模式处
理网卡传送的报文。考虑到多数用户的使用习惯,我们没有再做更多的优化工
作。 既然要最大限度地暴露问题,测试模型肯定要选择I/O密集型应用。
配好网卡IP,启用静态路由,再使用iptables加载一条策略,测试平台就被改造
成一台最原始的双口包过滤防火墙。我们按照RFC 2544规定,使用思博伦通信
提供的SmartBits 600网络性能测试仪进行了测试。结果表明,测试平台64字
节报文双向吞吐量只有29%,意味着实际处理能力还不到600Mbps。 8核至
强平台的性能如此不济?看看系统资源的占用情况就明白了:8个核中,有6个核
几乎没有负载; 其余两个却已经满载,且资源全部消耗在软中断处理流程中。显
然,为了优化性能, Linux Kernel使用了网卡与处理器核绑定的业务处理方
式。也就是说,跑包过滤防火墙这样的业务,理论上双核处理器即可达到同样效
果。虽然这种情况可以通过代码优化的方式解决,但对普通用户来说是不现实
的。 我们还在拔掉一颗处理器的情况下进行了同样的测试,64字节报文的
双向吞吐量上升至34%,较双路8核平台提高了17%。进过分析,造成这种情况的
原因应当是因为减少了两颗处理器间经北桥进行Cache同步这一步骤。 当
然,路由与包过滤防火墙只代表一类特殊的业务模型。真实情况中,大量上层应
用对CPU运算性能的要求要远远超过I/O,它们能否发挥出多路多核平台的真实
性能呢?联想到很多用户都使用配置较高的服务器搭配Snort进行入侵检测,我
们也搭建了这样一个测试环境。为了加大系统的运算负载,还特别加载了包含超
过一万条规则的海量特征库,并关闭了日志输出。由于该软件启动时必须指定监
听网口,所以系统内同时运行着两个Snort进程对接收到的报文进行检测。
我们使用SmartBits向服务器两个网口发送了64字节千兆线速流量,结果与预
先猜测有很大差异:8个核中的4个近乎闲置,另有两个核在满负载处理网卡接
收的报文,其余两个核的资源全部被Snort使用。即便是这两个核,分配给
2024年5月1日发(作者：亢俊材)
网卡革命―华为iNIC1000智能网卡评
测报告
因为工作的原因,我们经常在服务器上利用开源软件搭建一些测试环境,用
以考察新软件或硬件平台的实际性能。长期的测试让我们注意到,无论是单路、
双路还是四路平台,只要CPU核数超过两个,对I/O密集型应用的性能提升也只
是微乎其微。更有甚者,双路平台下某些应用的性能竟不及单路平台,显然有违
常理。 也并不是只有网络通信和安全方面的应用才算I/O密集型应
用。经常关注实验室评测报告的读者朋友们应该注意到,我们已经很久不用静态
页面脚本测试服务器性能了。甚至ASP、环境下负载较轻的脚本,测得
性能也只列为参考。这是因为,失败的HTTP请求总是过早地出现,此时CPU占用
率却并不高。而以往的经验(包括世界实验室评测标准中的规定)是,只有当处理
器整体利用率达到100%才会出现错误,这个临界值就是服务器针对当前脚本的
最大处理能力。 前段时间,我们特别针对这个问题进行了研究,希望找到真
正的原因。测试平台是一台配备了双路英特尔至强5472(3.0GHz,共 8核)、
5000P芯片组、8GB FB-DIMM、双口英特尔82575EB网络控制器的服务器,操作
系统采用了64位Red Hat Enterprise Linux 5.1,与多数商业用户目前实际使
用的配置相仿。2.6.18版的Linux内核也能很好地支持我们选用的硬件平台,
系统安装完毕即可开始使用。Kernel的配置文件表明,内核已开启NAPI模式处
理网卡传送的报文。考虑到多数用户的使用习惯,我们没有再做更多的优化工
作。 既然要最大限度地暴露问题,测试模型肯定要选择I/O密集型应用。
配好网卡IP,启用静态路由,再使用iptables加载一条策略,测试平台就被改造
成一台最原始的双口包过滤防火墙。我们按照RFC 2544规定,使用思博伦通信
提供的SmartBits 600网络性能测试仪进行了测试。结果表明,测试平台64字
节报文双向吞吐量只有29%,意味着实际处理能力还不到600Mbps。 8核至
强平台的性能如此不济?看看系统资源的占用情况就明白了:8个核中,有6个核
几乎没有负载; 其余两个却已经满载,且资源全部消耗在软中断处理流程中。显
然,为了优化性能, Linux Kernel使用了网卡与处理器核绑定的业务处理方
式。也就是说,跑包过滤防火墙这样的业务,理论上双核处理器即可达到同样效
果。虽然这种情况可以通过代码优化的方式解决,但对普通用户来说是不现实
的。 我们还在拔掉一颗处理器的情况下进行了同样的测试,64字节报文的
双向吞吐量上升至34%,较双路8核平台提高了17%。进过分析,造成这种情况的
原因应当是因为减少了两颗处理器间经北桥进行Cache同步这一步骤。 当
然,路由与包过滤防火墙只代表一类特殊的业务模型。真实情况中,大量上层应
用对CPU运算性能的要求要远远超过I/O,它们能否发挥出多路多核平台的真实
性能呢?联想到很多用户都使用配置较高的服务器搭配Snort进行入侵检测,我
们也搭建了这样一个测试环境。为了加大系统的运算负载,还特别加载了包含超
过一万条规则的海量特征库,并关闭了日志输出。由于该软件启动时必须指定监
听网口,所以系统内同时运行着两个Snort进程对接收到的报文进行检测。
我们使用SmartBits向服务器两个网口发送了64字节千兆线速流量,结果与预
先猜测有很大差异:8个核中的4个近乎闲置,另有两个核在满负载处理网卡接
收的报文,其余两个核的资源全部被Snort使用。即便是这两个核,分配给