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

作者：李烨楠

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

一、问题到底出在哪里?

系统架构简单明了：后台为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等工具都可以很方便的监控每秒网卡的接收及发送数据包数，查询结果如下：