首页
学习
活动
专区
工具
TVP
发布

“侦破”网卡传输能力的“个”案

一个平静的下午,在某监控大厅,应急召集令发出,一时间应急电话、汇报、询问声音响成一片。这是怎么了?原来某重要+系统应用交易严重超时,业务产生大量积压,无法顺利进行。

问题到底出在哪里?

系统架构简单明了:后台为Oracle RAC DB数据库,前台为12台AP,AP连接到DB做业务。而业务处理响应缓慢的情况发生在所有的AP上,因此焦点集中到DB服务器、网络、存储等共用的资源及设备上。

经过各方的共同排查,存储正常、数据库正常,却发现DB与AP的网络通信存在问题,ping延时严重,AP与DB、DB与DB之间的ping延时达到十几毫秒并且一直持续(正常时的ping延时只有0.3毫秒左右)。 于是,网络与系统开始协同检查抓包,发现网络链路上未见异常,十几毫秒的延时都消耗在DB主机的响应时间上,系统上可见所有资源均正常,网卡流量远未达到瓶颈,只有网卡收发包数一直较大。

抽丝剥茧的分析,提出解决方案

到底是什么具体问题呢?让我们先来看看问题主机的环境:Power780物理机,生产、带管、心跳网卡均为etherchannel绑定的网卡,使用的是两块千兆网卡,由于为主备模式,实际只有一块网卡处于工作状态。

根据之前我们在PowerVM虚拟化环境应急的经验,怀疑是单块千兆网卡转发包数的处理能力达到了瓶颈。通过AIX的topas、nmon等工具都可以很方便的监控每秒网卡的接收及发送数据包数,查询结果如下:

其中的I-pkts和O-pkts即是。一提到网卡,我们通常第一想到的就是带宽处理能力,像千兆、万兆、全双工等等指标更多展示的就是带宽有多大,但很少有人关心网卡的包处理能力上限在哪儿,到底是每秒1万、10万还是100万。为什么呢?因为极少有人会遇到包数转发处理能力的瓶颈,这种情况只出现在业务压力非常大、平均网络包size非常小的系统上,否则通常包数还没达到瓶颈呢,带宽已经满了,但是这种系统恰恰被我们碰上了!而且不止一次!

发生问题的DB主机,当时单块千兆网卡的收发包总数达到了15万左右,并且现象持续存在,一直到应用进行了流控之后,ping延时才得到了缓解,业务才逐渐恢复,这会是问题的症结么?

我们据此提出了紧急的解决方案:

扩容网卡的包处理能力!一块处理不过来就增加多块,紧急改变网卡的绑定模式,改为load balance,并使并发的网卡达到三块。

问题解决:

之后业务高峰再到来后,三块网卡并发处理,收发包总数峰值达到了22万,可见之前的瓶颈限制了总转发处理能力从而造成了积压。调整之后一通百通, ping延时的现象也不复存在了。

小马过河的测试

千兆网卡、万兆网卡的每秒转发包数处理能力上限到底有多大的问题,引起了我们的思考,于是转而求助硬件厂商,希望得到有参考价值的技术指标,然而厂商也拿不出明确的包转发处理能力的相关指标,看来大家更关心的都是带宽处理能力。

这使我们想到了小马过河的故事,既然没有现成的指标给我们参考,我们就在自己的环境上测出一个相对可信的处理能力上限,求人不如求己。

根据我们在准生产环境上的压力测试,结论如下:

1、对于物理机:

1)千兆网卡单卡单向包的数量极限大约为每秒8 万个,收发一致,也就是说收发总处理能力上限为每秒16万左右。

2)万兆网卡单卡单向包的数量极限大约为每秒19万个,收发一致,也就是说收发总处理能力上限为每秒38万左右。

2、对于PowerVM虚拟化主机:

由于做了网卡的虚拟化,由hypervisor虚拟化层负责虚拟网卡的转发处理等,网卡的包转发处理能力较物理机有较大的损失。

两块万兆网卡做load balance绑定后提供给VIOS做成虚拟网卡映射给VIOC使用,当网卡每秒收发包总数超过10万时即可能对网络的转发造成瓶颈从而影响业务处理。

这部分内容属于少有人关注的性能瓶颈,我们通过对这个事件的处理、应急以及在这之后做的各种测试,将测试数据和总结的经验分享给大家!

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180316G1AMJE00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券