一 背景

有时候,需要关注下网络的是否丢包,特别是高带宽情况下测试系统的性能的时候, 这次我们在测试很小的流量的情况下,用ifconfig命令查看发现丢包:

watch ifconfig eno2

[root@localhost ~]# ifconfig eno2 eno2: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 ether 78:ac:44:0f:16:00 txqueuelen 1000 (Ethernet) RX packets 1445302589 bytes 255819232376 (238.2 GiB) RX errors 0 dropped 43330140683 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

dropped 数据在一直增加.

二 分析2.1 实际网卡速率

既然没有错误,那么看看网卡的支持的速率多大,是否可以满足现有的要求:

[root@localhost ~]# ethtool eno2 | egrep 'Speed|Duplex' Speed: 10000Mb/s Duplex: Full

10Gbps大于测试的速率,这个原因排除.

2.2 ethtool 分析具体丢包原因

通过ethtool -S来查看丢包原因:

[root@localhost ~]# ethtool -S eno2|grep drop rx_dropped: 1996379212 tx_dropped: 0 port.rx_dropped: 0 port.tx_dropped_link_down: 0 [root@localhost ~]# ethtool -S eno2|grep error rx_errors: 0 tx_errors: 0 rx_length_errors: 0 rx_crc_errors: 0 port.tx_errors: 0 port.rx_crc_errors: 0 port.rx_length_errors: 0

发现除了丢包数据,并没有明显的错误.

网络抓包分析  排除故障(网卡抓包丢包排查一)(1)

####2.2.1 rx_missed_errors此原因是ring-buffer不够了,可能原因来的速率确实很大,超出了预期,如果是临时的大流量,可以通过增加rx的ring-buffer大小来解决,这里面的ring-buffer大小是指存的帧的数量,而不是字节数.

# ethtool -g eno2 Ring parameters for eno2: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 1024 RX Mini: 0 RX Jumbo: 0 TX: 512

2.2.2 overruns

这玩意增大,说明数据包还没到ring buffer就被物理网卡丢弃了,可能原因是中断不均衡造成的. 如果没有做线程绑定cpu的设置,就要看下是否开启了中断均衡:

service irqbalance status

如果指定了处理网络包的线程绑定了具体的CPU,则需要将系统自带的中断均衡程序关闭:

service irqbalance stop

注意,处理网络包的线程绑定cpu后, 可以达到的目的是网络包的中断是这个线程处理,而且后续也是 这个线程再进一步分析包,好处是缓存可以重用,不用因为切换不同线程导致缓存失效的问题. 特别是NUMA架构,要将网卡归属NUMA节点的CPU绑定给线程,查看办法:

lscpu ... NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39 ...

网卡归属的NUMA节点查看:

[root@localhost ~]# cat /sys/class/net/eno2/device/numa_node 0

我们就可以把NUMA节点0上的CPU绑定给线程,用于处理eno2网卡的数据包。

如何把网卡的队列的中断处理绑定到特定的cpu上,虽然可以手工设置,但是比较麻烦,网上有个脚本:set_irq_affinity ,通过这个脚本可以方便地设置:

set_irq_affinity 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 eno2

即用0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 这些cpu来处理eno2网卡的中断。 我们可以将eno2的网卡队列改成了20,这样刚好可以一一对应,更改办法:

ethtool -L eno2 combined 20

负载均衡相关设置:

ethtool -K eno2 rxhash on ethtool -K eno2 ntuple on for proto in tcp4 udp4 ah4 esp4 sctp4 tcp6 udp6 ah6 esp6 sctp6 do ethtool -N eno2 rx-flow-hash ${proto} sd done

为了让一个流所属的双向包都均衡到同一个网卡队列中,需要设置对称哈希算法的key,设置方法如下:

ethtool -X eno2 hkey 6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A equal 20

2.2.3 rx_drop

这里面直观看是丢包数,其实不仅仅是丢包数,比较坑。 The RT and RHEL7 kernels contains code that updates the rx_dropped counter for other non-error conditions.

The softnet backlog full Bad VLAN tags Packets received with unknown or unregistered protocols IPv6 frames when the server is configured only for ipv4

具体可以参考:

[https://access.redhat.com/solutions/657483](https://access.redhat.com/solutions/657483)

如果想看实际网卡上是否有丢包,可以通过ethtool -S eno2|grep error,想看下重传率,可以通过 netstat -s 查看:

网络抓包分析  排除故障(网卡抓包丢包排查一)(2)

奇怪的是,同样的包回放,如果不处理,只收包就不丢包,这样上面的原因就说不过去了,继续排查。

三 程序排查3.1 首先是磁盘io排查

因为程序有大量写文件操作,所以看看是不是磁盘的IO满了造成的丢包。

iostat -x 1 10

磁盘IO并未达到瓶颈。

yum install iotop iotop -oP

也未看到特别大的磁盘IO,排除这个问题。

3.2 CPU

线程是绑定cpu的方式,而且整体来说占用很均衡,说明不存在cpu不均衡导致中断处理不过来造成的丢包问题。

top -Hp pid

查看关键线程的cpu占用情况,比较均衡,无瓶颈。

3.3 内存查看

yum install numactl #查看内存占用 numastat -m

没发现什么异常,内存占用很均衡。

3.4 排查中断

通过以下命令看下,软中断在各个cpu上是否均衡,如果不均衡按照overrun的办法均衡下。

watch cat /proc/softirqs

四 其他

目前该排查的都排查了,包括驱动程序,已经按照安装了最新的驱动程序,仍然存在丢包问题。 由于是采用netmap库抓包,所以下一步要进行源码或驱动排查。 如果不是网卡丢包,而是正常的网络丢包,可以参考下安装下dropwatch排查

#yum install dropwatch #dropwatch -l kas >start

具体可以参考下面第一个链接:

[https://vcpu.me/categories/](https://vcpu.me/categories/) [https://blog.huoding.com/2020/04/27/814](https://blog.huoding.com/2020/04/27/814)

,