网络丢包排查方法

简介: 网络丢包排查方法

阅读目录

回到顶部

一、硬件网卡丢包

1.Ring Buffer溢出

Ring Buffer(环形缓冲区)溢出是指当往一个已经满了的环形缓冲区中写入数据时,会覆盖之前存储在缓冲区中的数据。这种情况通常发生在写入速度快于读取速度的情况下。

1.查看Ring Buffer满而丢弃的包统计(fifo字段)
$ ethtool -S eth0|grep rx_fifo
rx_fifo_errors: 0
$ cat /proc/net/dev
Inter-|Receive | Transmitface |bytes packets errs drop fifo frame compressed 
multicast|bytes packets errs drop fifo colls carrier compressed
eth0: 17253386680731 42839525880 0 0 0 0 0 244182022 14879545018057 41657801805 0 0 0 0 0 0
2.查看网卡Ring Buffer最大值和当前设置
ethtool -g eth0
3.修改网卡接收与发送硬件缓存区大小
ethtool -G eth0 rx 4096 tx 4096

2.网卡端口协商丢包

1.查看网卡和上游网络设备协商速率和模式
➜  ~ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.19.6.105  netmask 255.255.192.0  broadcast 172.19.63.255
        ether 00:16:3e:18:9f:57  txqueuelen 1000  (Ethernet)
        RX packets 11631990  bytes 3611913450 (3.3 GiB)
        RX errors 0  dropped 216  overruns 0  frame 0
        TX packets 10461655  bytes 2946312189 (2.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
➜  ~ ethtool -i eth0
driver: virtio_net
version: 1.0.0
firmware-version:
expansion-rom-version:
bus-info: 0000:00:03.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
➜  ~ ethtool -S eth0
no stats available 
➜  ~ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth0: 3611947360 11632489    0    0    0     0          0         0 2946427291 10462601    0    0    0     0       0          0
    lo:    4215      78    0    0    0     0          0         0     4215      78    0    0    0     0       0          0
2.重新协商
ethtool -r eth1/eth0
3.强制设置端口速率
ethtool -s eth1 speed 1000 duplex full autoneg off

3.网卡流控丢包

网卡流控丢包问题通常是由于发送和接收速率不匹配导致的

1.查看网卡的流控设置
ethtool -a eth0
确保发送方和接收方速率一致:如果发送方的速率大于接收方,则可能会出现丢包情况。你可以通过调整两端设备的速率来解决该问题
2.关闭网卡流控
ethtool -A ethx autoneg off //自协商关闭
ethtool -A ethx tx off //发送模块关闭
ethtool -A ethx rx off //接收模块关闭

回到顶部

二、网卡驱动丢包

1.查看丢包信息

ifconfig eth0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

       inet 192.168.100.134  netmask 255.255.255.0  broadcast 192.168.100.255

       inet6 fe80::20c:29ff:feb4:5883  prefixlen 64  scopeid 0x20<link>

       ether 00:0c:29:b4:58:83  txqueuelen 1000  (Ethernet)

       RX packets 102430  bytes 137887910 (131.5 MiB)

       RX errors 0  dropped 0  overruns 0  frame 0 #主要此行

       TX packets 27457  bytes 3144190 (2.9 MiB)

       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


字段解析:


(1)RX errors:表示总的收包的错误数量,还包括too-long-frames错误,Ring Buffer 溢出错误,crc 校验错误,帧同步错误,fifo overruns 以及 missed pkg 等等。

(2)RX dropped:表示数据包已经进入了 Ring Buffer,但是由于内存不够等系统原因,导致在拷贝到内存的过程中被丢弃。

(3)RX overruns:overruns 意味着数据包没到 ring buffer 就被网卡物理层给丢弃了,当驱动处理速度跟不上网卡收包速度时,驱动来不及分配缓冲区,NIC 接收到的数据包无法及时写到 skb,就会产生堆积。当 NIC 内部缓冲区写满后,就会丢弃部分数据,引起丢包。

这部分丢包为 rx_fifo_errors,在 /proc/net/dev 中体现为 fifo 字段增长,在 ifconfig 中体现为 overruns 指标增长,CPU无法及时的处理中断是造成 ring ruffer 满的原因之一,例如中断分配的不均匀。或者 ring buffer 太小导致的。

(4)RX frame: 表示 misaligned 的 frames,对于 TX 的来说,出现上述 counter 增大的原因主要包括 aborted transmission, errors due to carrirer, fifo error, heartbeat erros 以及 windown error,而 collisions 则表示由于 CSMA/CD 造成的传输中断

2.驱动溢出丢包

netdev_max_backlog是内核从NIC收到包后,交由协议栈(如IP、TCP)处理之前的缓冲队列。每个CPU核都有一个backlog队列,与Ring Buffer同理,当接收包的速率大于内核协议栈处理的速率时,CPU的backlog队列不断增长,当达到设定的netdev_max_backlog值时,数据包将被丢弃。

1.查看是否发生netdev backlog队列溢出
00000027 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00007f82 00000000 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000
每一行代表每个CPU核的状态统计,从CPU0依次往下
每一列代表一个CPU核的各项统计:
第一列代表中断处理程序收到的包总数;
第二列即代表由于netdev_max_backlog队列溢出而被丢弃的包总数。从上面的输出可以看出,这台服务器统计中,并没有因为netdev_max_backlog导致的丢包,netdev_max_backlog(接收) 和 txqueuelen(发送) 相对应。
2.netdev backlog队列溢出解决方案
netdev_max_backlog的默认值是1000,在高速链路上,可能会出现上述第二统计不为0的情况,可以通过修改内核参数net.core.netdev_max_backlog来解决
sysctl -w net.core.netdev_max_backlog=2000

3.频繁网卡IRQ导致丢包

1.查看是否存在网卡 IRQ频繁导致的丢包
00000027 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00007f9c 00000000 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000
第三列一直在增加的话需要,表示 soft IRQ 获取的 CPU 时间太短,来不及处理足够多的网络包,那么需要增大 netdev_budget 值。
2.解决IRQ丢包
budget 默认 300,可以调整
sysctl -w net.core.netdev_budget=600

4.单核负载高导致丢包

单核CPU软中断占有高, 导致应用没有机会收发或者收包比较慢,即使调整netdev_max_backlog队列大小仍然会一段时间后丢包,处理速度跟不上网卡接收的速度

1.查看
mpstat -P ALL 1
Linux 3.10.0-957.el7.x86_64 (localhost.localdomain)     05/07/2024     _x86_64_    (2 CPU)
03:09:59 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
03:10:00 PM  all    0.52    0.00    2.58    0.00    0.00    0.52    0.00    0.00    0.00   96.39
03:10:00 PM    0    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
03:10:00 PM    1    0.00    0.00    5.21    0.00    0.00    1.04    0.00    0.00    0.00   93.75
单核软中断占有100%,导致应用没有机会收发或者收包比较慢而丢包
2.解决
2.1调整网卡RSS队列配置
查看:ethtool -x eth0;
调整:ethtool -X eth0 xxxx;

回到顶部

三、内核协议栈丢包

1.neighbor系统arp丢包

arp_ignore参数的作用是控制系统在收到外部的arp请求时,是否要返回arp响应。

1.查看

sysctl -a|grep arp_ignore


2.解决

根据实际场景设置对应值

2.arp_filter配置丢包

在多接口系统里面,这些接口都可以回应arp请求,导致对端有可能学到不同的mac地址,后续报文发送可能由于mac地址和接收报文接口mac地址不一样而导致丢包,arp_filter主要是用来适配这种场景

1.查看
sysctl -a | grep arp_filter
2.解决方案
根据实际场景设置对应的值,一般默认是关掉此过滤规则,特殊情况可以打开;
0:默认值,表示回应arp请求的时候不检查接口情况;
1:表示回应arp请求时会检查接口是否和接收请求接口一致,不一致就不回应;

3.arp表满导致丢包

1.查看
查看arp状态:cat /proc/net/stat/arp_cache ,table_fulls统计:
查看dmesg消息(内核打印)
dmesg|grep neighbour
neighbour: arp_cache: neighbor table overflow!
查看当前arp表大小
ip n|wc -l
查看系统配额
sysctl -a |grep net.ipv4.neigh.default.gc_thresh
gc_thresh1:存在于ARP高速缓存中的最少层数,如果少于这个数,垃圾收集器将不会运行。缺省值是128。
gc_thresh2 :保存在 ARP 高速缓存中的最多的记录软限制。垃圾收集器在开始收集前,允许记录数超过这个数字 5 秒。缺省值是 512。
gc_thresh3 :保存在 ARP 高速缓存中的最多记录的硬限制,一旦高速缓存中的数目高于此,垃圾收集器将马上运行。缺省值是1024
2.解决方案
根据实际arp最大值情况(比如访问其他子机最大个数),调整arp表大小
$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=1024
$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=2048
$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=4096
$ sudo sysctl  -p

4.arp请求缓存队列溢出丢包

1.查看

cat /proc/net/stat/arp_cache ,unresolved_discards是否有新增计数


2.解决方案

根据客户需求调整缓存队列大小unres_qlen_bytes:

回到顶部

四、TCP/UDP协议丢包

1.分片重组丢包

1.查看
netstat -s|grep timeout
601 fragments dropped after timeout
2.解决方法
2.1调整超时时间
net.ipv4.ipfrag_time = 30
sysctl -w net.ipv4.ipfrag_time=60
2.2 调整分片内存大小
netstat -s|grep reassembles
8094 packet reassembles failed
解决方案:
调整参数
net.ipv4.ipfrag_high_thresh 
net.ipv4.ipfrag_low_thresh
2.3关闭分片安全检查
netstat -s|grep reassembles
8094 packet reassembles failed
解决方案: 把ipfrag_max_dist设置为0
2.4分片hash bucket冲突链太长超过系统默认值128
dmesg|grep “Dropping fragment”
inet_frag_find: Fragment hash bucket 128 list length grew over limit. Dropping fragment.
解决方案:热补丁调整hash大小
2.5 系统内存不足,创建新分片队列失败
netstat -s|grep reassembles
8094 packet reassembles failed
dropwatch -l kas #dropwatch查看丢包位置
解决方案
增大系统网络内存
net.core.rmem_default 
net.core.rmem_max 
net.core.wmem_default
系统回收内存
echo 3 > /proc/sys/vm/drop_caches

2.TIME_WAIT过多丢包

大量TIMEWAIT出现,并且需要解决的场景,在高并发短连接的TCP服务器上,当服务器处理完请求后立刻按照主动正常关闭连接。。。这个场景下,会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高,此时部分客户端就会显示连接不上

1.查看
dmsg
TCP: time wait bucket table overflow;
系统配置
sysctl -a|grep tcp_max_tw_buckets
解决方案:
1. tw_reuse,tw_recycle 必须在客户端和服务端timestamps 开启时才管用(默认打开)
2. tw_reuse 只对客户端起作用,开启后客户端在1s内回收;
3. tw_recycle对客户端和服务器同时起作用,开启后在3.5*RTO 内回收,RTO 200ms~ 120s具体时间视网络状况。内网状况比tw_reuse稍快,公网尤其移动网络大多要比tw_reuse 慢,优点就是能够回收服务端的TIME_WAIT数量;
在服务端,如果网络路径会经过NAT节点,不要启用net.ipv4.tcp_tw_recycle,会导致时间戳混乱,引起其他丢包问题;
4. 调整tcp_max_tw_buckets大小,如果内存足够:

3.内存不足导致丢包

1.查看
dmesg|grep “out of memory”
系统配置
cat /proc/sys/net/ipv4/tcp_mem
cat /proc/sys/net/ipv4/tcp_rmem
cat /proc/sys/net/ipv4/tcp_wmem
2.解决方案
根据TCP业务并发流量,调整系统参数,一般试着增大2倍或者其他倍数来看是否缓解;
sysclt -w net.ipv4.tcp_mem=
sysclt -w net.ipv4.tcp_wmem=
sysclt -w net.ipv4.tcp_rmem=
sysctl -p

4.TCP超时丢包

1.查看当前端到端网络质量
hping -S 9.199.10.104 -A
2.解决方案
关闭Nagle算法,减少小包延迟;
关闭延迟ack:
sysctl -w net.ipv4.tcp_no_delay_ack=1

5.TCP乱序丢包

#修改TCP无序传送的容错率

sysctl -a|grep tcp_reordering

抄自于:https://mp.weixin.qq.com/

相关文章
|
11天前
|
机器学习/深度学习 数据采集 人工智能
基于Huffman树的层次化Softmax:面向大规模神经网络的高效概率计算方法
层次化Softmax算法通过引入Huffman树结构,将传统Softmax的计算复杂度从线性降至对数级别,显著提升了大规模词汇表的训练效率。该算法不仅优化了计算效率,还在处理大规模离散分布问题上提供了新的思路。文章详细介绍了Huffman树的构建、节点编码、概率计算及基于Gensim的实现方法,并讨论了工程实现中的优化策略与应用实践。
58 15
基于Huffman树的层次化Softmax:面向大规模神经网络的高效概率计算方法
|
1月前
|
Linux iOS开发 网络架构
如何使用 Ping 命令监测网络丢包情况?
如何使用 Ping 命令监测网络丢包情况?
139 48
|
3天前
|
域名解析 缓存 网络协议
优化Lua-cURL:减少网络请求延迟的实用方法
优化Lua-cURL:减少网络请求延迟的实用方法
|
28天前
|
安全 Windows
【Azure Cloud Service】在Windows系统中抓取网络包 ( 不需要另外安全抓包工具)
通常,在生产环境中,为了保证系统环境的安全和纯粹,是不建议安装其它软件或排查工具(如果可以安装,也是需要走审批流程)。 本文将介绍一种,不用安装Wireshark / tcpdump 等工具,使用Windows系统自带的 netsh trace 命令来获取网络包的步骤
67 32
|
9天前
|
Web App开发 网络协议 安全
网络编程懒人入门(十六):手把手教你使用网络编程抓包神器Wireshark
Wireshark是一款开源和跨平台的抓包工具。它通过调用操作系统底层的API,直接捕获网卡上的数据包,因此捕获的数据包详细、功能强大。但Wireshark本身稍显复杂,本文将以用抓包实例,手把手带你一步步用好Wireshark,并真正理解抓到的数据包的各项含义。
45 2
|
20天前
|
域名解析 运维 网络协议
网络诊断指南:网络故障排查步骤与技巧
网络诊断指南:网络故障排查步骤与技巧
79 7
|
26天前
|
机器学习/深度学习 数据采集 算法
机器学习在医疗诊断中的前沿应用,包括神经网络、决策树和支持向量机等方法,及其在医学影像、疾病预测和基因数据分析中的具体应用
医疗诊断是医学的核心,其准确性和效率至关重要。本文探讨了机器学习在医疗诊断中的前沿应用,包括神经网络、决策树和支持向量机等方法,及其在医学影像、疾病预测和基因数据分析中的具体应用。文章还讨论了Python在构建机器学习模型中的作用,面临的挑战及应对策略,并展望了未来的发展趋势。
89 1
|
1月前
|
安全 算法 网络安全
量子计算与网络安全:保护数据的新方法
量子计算的崛起为网络安全带来了新的挑战和机遇。本文介绍了量子计算的基本原理,重点探讨了量子加密技术,如量子密钥分发(QKD)和量子签名,这些技术利用量子物理的特性,提供更高的安全性和可扩展性。未来,量子加密将在金融、政府通信等领域发挥重要作用,但仍需克服量子硬件不稳定性和算法优化等挑战。
|
5天前
|
SQL 安全 网络安全
网络安全与信息安全:知识分享####
【10月更文挑战第21天】 随着数字化时代的快速发展,网络安全和信息安全已成为个人和企业不可忽视的关键问题。本文将探讨网络安全漏洞、加密技术以及安全意识的重要性,并提供一些实用的建议,帮助读者提高自身的网络安全防护能力。 ####
42 17
|
15天前
|
存储 SQL 安全
网络安全与信息安全:关于网络安全漏洞、加密技术、安全意识等方面的知识分享
随着互联网的普及,网络安全问题日益突出。本文将介绍网络安全的重要性,分析常见的网络安全漏洞及其危害,探讨加密技术在保障网络安全中的作用,并强调提高安全意识的必要性。通过本文的学习,读者将了解网络安全的基本概念和应对策略,提升个人和组织的网络安全防护能力。
下一篇
DataWorks