hadoop出现error包问题记录

前段时间，我公司发现大部分hadoop服务器有重传数据包和error包现象，且重传率经常超过1%。zabbix告警hadoop主机有error包出现。收到大量类似如下告警信息：

Trigger: eth1 incoming error packets increase

Trigger status: PROBLEM

Trigger severity: Warning

Trigger URL:

Event ID: 61317015

Item values:

Incoming errors on eth1 (hdp4.bi.bj2.xxxx.com:net.if.in[eth1, errors]): 153

收到告警之后，我们立即查看zabbix监控和网卡信息，经过确认之后，发现hadoop主机确实存在error包，通过zabbix监控如下图所示：

第二阶段

故障定位：

　　通过tcpdump抓包来看，的确有大量的重传和快速重传发生。系统同时有error包出现，考虑到运维人员对数据包重传思路比较清晰，因此运维人员从解决重传问题入手。从zabbix上观察hub交换机的流量，峰值在5Gb/s左右，网口是万兆光口，运维人员初步判断不是流量超限导致。后续通过观察交换机的状态运维人员发现，<包重传>/<流量达到峰值>/<网口discard包> 这三个量具有强烈的相关性，基本是同时出现。因此，运维人员怀疑是交换机在大流量的情况下产生丢包。以下几图是调整前的交换机和服务器流量图，说明重传和交换机discard紧密相关。

交换机流量峰值：

交换机discard：

服务器重传：

　　与交换机厂商联系后，建议在交换机上添加流量统计功能。经过一段时间观察，发现在网卡达到峰值后，接入层交换机连接服务器的网口的入方向和对端接入层交换机连接服务器的网口的出方向数据包个数的差异会发生变化。说明，从server1发往server2的数据包发生丢失。经检查发现，zabbix采集网卡流量数据是以60sec为一个周期，导致网卡流量在峰值时失真。运维人员重新建立新的监控项，每3sec为一个周期获取数据。发现果然网卡峰值超过了10G。以下图所示，是以3sec为周期获取数据的网卡流量图。

原因分析：

　　服务器使用bond mode 1方式，基本上所有服务器都主用第一块网卡，也就是说绝大部分流量都走第一个交换机，H3C交换机的特性是本地流量优先处理，造成的后果就是，第一个交换机网口流量占满，然后才使用第二个交换机，在此期间发生部分数据包丢失。

故障解决：

　　1.改为网卡模式从mode1主备到mode4负载均衡。mode4使用hash方式选择主用网卡，既利用了两块网卡的传输能力，平衡交换机的流量负载，又避免了数据包乱序的可能性；

　　2.Hub交换机和access交换机扩展端口。从2根万兆网线扩展为6根万兆网线，传输流量峰值达到了60Gbps，避免由于网口拥塞导致丢包；

第二阶段

故障分析：

　　重传问题解决后，发现error包变多。对比cat /proc/net/softnet_stat结果，发现第三列一直在增加，表明软中断获取的cpu处理时间不足。按照redhat官方调优文档，将net.core.netdev_budget的值从300增加到600。之前的300是千兆网卡的默认配置，由于hdp都是万兆网卡，因此设置为2000。

　　配置变更之后error包情况有好转，但未消除，继续排查。观察系统发现error包发生时，cpu中断溢出计数(/proc/net/softnet_stat)就会增加。通过阅读redhat官方网络调优文档，怀疑该现象是由于cpu中断溢出导致。经过观察cpu中断，发现只有前6个中断被平均分配到了cpu1,3,5,7,9,11上，剩下的中断仍然在cpu0上。仔细阅读中断脚本，发现该脚本由于考虑到numa的问题，仅处理了网卡上6个中断的情况。由于现网大量服务器都使用仅有5个中断的千兆网卡，该脚本并未造成问题。但是对于万兆网卡的9个中断，这样处理导致剩下的3个中断仍然留在cpu0上面。运维人员推测，这就是每次都是cpu0中断溢出的原因。

　　运维人员修改脚本，将后面3个中断分配到了cpu13,15,17上面。修改中断后，error包问题并没有得到缓解，反而有增加的趋势。由于error与网卡关联比较紧密，运维人员尝试使用ethtool -S p2p[1,2]命令查看网卡计数器。发现每次error增多时，cpu中断溢出计数(/proc/net/softnet_stat)就会增加，同时rx_brb_discard和rx_brb_truncate计数会增加。通过查找redhat官方调优文档（https://access.redhat.com/solutions/2127651）发现，该问题极有可能是操作系统启用了CPU节能模式导致。

　　通过命令cat /sys/module/intel_idle/parameters/max_cstate查看系统参数，确认服务器上启用了节能模式。关闭节能模式后，发现tcpExtListenDrops问题基本解决，印证了之前猜想，也就是说cpu处理不及时，导致tcp的syn请求溢出。关闭CPU节能模式，但，让人费解的是，error包反而更多了，甚至有刷屏的趋势。阅读numa的相关文档，发现当cpu访问非本地内存的时候，效率会很低。仔细观察系统中断，都是默认放到了cpu0上面，从numa角度来讲，就是node0。而经过调优后，所有的网卡中断都在node1上面。运维人员怀疑error包刷屏的问题是由于cpu中断部署在了node1上引起的。同时运维人员注意到，有部分启用了irqbalance的服务器，和部分没有调整网卡中断的服务器，error包发生的概率比较低。

　　同一天内，hdp32的error包数量是hdp29的error包数量的十倍，hdp32未调整中断，而hdp29调整中断到node1。运维人员尝试将所有网卡中断调整到了node0上，也就是与系统中断都处于一个node上。经过实践，发现error数量急剧减少。但是，运维人员发现还有几台服务器hdp[3-9]的error包数量仍然很高。经过观察发现，这几台服务器的网卡中断系统默认设置在了node1上面，与其他的服务器不同。运维人员尝试重新将中断设置在了node1上面，error包数量减少很多。如下两个图对比可以看出调整前后error包数量变化。