linux下网络丢包问题处理--overruns不断增加

本文针对网络接收过载问题,详细解析了overruns错误的概念及其产生的原因,并提供了具体的诊断步骤和解决方案,包括调整缓冲区大小。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近业务上老有问题,查看发现overruns值不断增加,学习了一下相关的知识。

发现数值也在不停的增加。G 了一下,发现这些 errors, dropped, overruns 表示的含义还不大一样。
eth2      Link encap:Ethernet  HWaddr 00:8C:FA:F1:DA:78  
          inet addr:10.249.2.112  Bcast:10.249.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26191508237 errors:0 dropped:0 overruns:45732243 frame:0
          TX packets:20141298524 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4684832167216 (4.2 TiB)  TX bytes:4670328443919 (4.2 TiB)
          Memory:c7200000-c7280000 
RX errors: 表示总的收包的错误数量,这包括 too-long-frames 错误,Ring Buffer 溢出错误,crc 校验错误,帧同步错误,fifo overruns 以及 missed pkg 等等。
RX dropped: 表示数据包已经进入了 Ring Buffer,但是由于内存不够等系统原因,导致在拷贝到内存的过程中被丢弃。
RX overruns: 表示了 fifo 的 overruns,这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的,而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显,overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了,而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一,上面那台有问题的机器就是因为 interruprs 分布的不均匀(都压在 core0),没有做 affinity 而造成的丢包。
RX frame: 表示 misaligned 的 frames。

1、先查看硬件情况
一台机器经常收到丢包的报警,先看看最底层的有没有问题:
# ethtool  eth2 | egrep 'Speed|Duplex'
        Speed: 1000Mb/s
        Duplex: Full

# ethtool  -S eth2 | grep crc
     rx_crc_errors: 0
Speed, Duplex, CRC 之类的都没问题,基本可以排除物理层面的干扰。
 
2、通过 ifconfig 可以看到 overruns 字段在不停的增大:
for i in `seq 1 100`; do ifconfig eth2 | grep RX | grep overruns; sleep 1; done
这里一直增加
RX packets:26191785302 errors:0 dropped:0 overruns:45732243 frame:0

3、查看buffer大小
找了一些国外的文章,可以通过ethtool来修改网卡的buffer size ,首先要网卡支持,我的服务器是是INTEL 的1000M网卡,我们看看ethtool说明 
-g   –show-ringQueries the specified ethernet device for rx/tx ring parameter information.
-G   –set-ringChanges the rx/tx ring parameters of the specified ethernet device.

查看当前网卡的buffer size情况ethtool -g eth0   
Ring parameters for eth0:
Pre-set maximums:
RX: 4096RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256

4、修改buffer size大小
ethtool -G eth2 rx 2048
ethtool -G eth2 tx 2048

查看丢包
[root@appserver1 network-scripts]# cat /proc/net/dev | column  -t
Inter-|             Receive      |        Transmit
face                |bytes       packets  errs      drop      fifo  frame  compressed  multicast|bytes  packets      errs  drop  fifo  colls  carrier  compressed
lo:1697064305645    4937104295   0        0         0         0     0      0           1697064305645    4937104295   0     0     0     0      0        0
eth0:72829268758    343814516    0        21338     0         0     0      9764241     74743576507      418943369    0     0     0     0      0        0
eth1:5826509023     48719872     0        0         0         0     0      11358883    127451707        1107964      0     0     0     0      0        0
eth2:4684766978372  26191366713  0        0         45732243  0     0      278436828   4670300836866    20141168183  0     0     0     0      0        0
eth3:               0            0        0         0         0     0      0           0                0            0     0     0     0      0        0           0
bond0:              0            0        0         0         0     0      0           0                0            0     0     0     0      0        0           0
[root@appserver1 network-scripts]# netstat -i | column  -t
Kernel  Interface  table
Iface   MTU        Met    RX-OK        RX-ERR  RX-DRP  RX-OVR    TX-OK        TX-ERR  TX-DRP  TX-OVR  Flg
eth2    1500       0      26191244868  0       0       45732243  20141056331  0       0       0       BMRU
lo      16436      0      4937053994   0       0       0         4937053994   0       0       0       LRU


问题:接受队列溢出产生错误,当抵达的包多于内核可以处理的包时,计算机会产生漫溢(overruns)。输入队列达到其上限(max_backlog)时,多抵达的那些包会全部被丢弃掉。
<think>我们正在排查网络丢包和延迟问题。根据用户需求,我们需要结合之前的DHCP故障排查经验,但重点转向丢包和延迟。引用[1]和[2]提到了网络丢包是常见故障,可能由多种因素引起,包括网络拥塞、硬件故障、配置错误等。我们将从基础到深入逐步排查。排查思路:1.确定问题范围和模式:是持续丢包还是间歇性?是特定目标还是普遍?延迟是否伴随丢包?2.分层排查:物理层、数据链路层、网络层、传输层等。3.使用工具:ping,traceroute, mtr,netstat, iperf,Wireshark等。具体步骤:###一、问题定位与基础测试1. **确定故障范围**-测试不同目标:```bashping -c1008.8.8.8#测试公网地址ping -c100192.168.1.1 #测试网关ping-c100同网段其他主机 #测试局域网内```-结果分析:-如果仅公网丢包问题可能出在出口或ISP链路-如果仅网关丢包问题可能在本地网络或网关设备-如果局域网内就丢包问题可能在物理层或二层2. **持续监控工具**-使用`mtr`(结合traceroute和ping):```bashmtr-r-c1008.8.8.8#生成100个包的报告,显示每一跳的丢包率和延迟```-关键指标:-最后一跳丢包率>1%即异常[^1]-中间跳出现丢包但最后一跳不丢包,可能是设备配置丢弃探测包(正常)###二、物理层与数据链路层排查1. **物理连接检查**-网线/光纤:更换线缆测试,检查接口氧化-网卡状态:```bashethtooleth0#Linux查看网卡状态(关注Speed,Duplex, Errors)netstat -i#查看接口错误计数(I-Err, O-Err)```-错误类型分析:-`CRC errors`:物理层干扰或线缆问题-`collisions`:半双工冲突(现代网络少见)-`overruns`:系统处理能力不足2.**二层环路与广播风暴**-检查交换机端口状态:```bashshow interfaces|include errors|broadcast#查看错误包和广播包```-广播风暴特征:-端口广播包>10,000pps(每秒包数)- CPU利用率突增-防护措施:-启用STP(生成树协议)-配置广播风暴控制:```bashinterface GigabitEthernet0/1storm-control broadcastlevel10#限制广播流量为10%```###三、网络层与路由分析1.**路由路径验证**-使用`traceroute`:```bashtraceroute-n8.8.8.8#不解析域名,显示路径```-异常情况:-路由循环(同一IP重复出现)-路径不对称(去程和回程路径不一致)2. **MTU不匹配**-症状:大包丢包,小包正常-测试方法:```bashping -s1472-Mdo8.8.8.8# Linux(1472+28=1500)ping -l1472-f8.8.8.8#Windows```-如果1472成功,1500失败,则存在MTU问题-解决方案:调整MTU或启用分片(避免路径MTU黑洞)###四、传输层与拥塞控制1. **TCP重传分析**-使用Wireshark过滤:```bashtcp.analysis.retransmission#显示重传包```-重传率>1%即需关注[^2]-常见原因:-网络拥塞(Bufferbloat)-不稳定的无线连接2.**带宽拥塞检测**-使用`iperf3`测试带宽:```bash#服务端iperf3 -s#客户端iperf3-cserver_ip -t30 -P10#10个并行流测试30秒```-观察抖动(Jitter)和丢包-丢包集中在高带宽时→带宽不足-持续高抖动→线路质量差###五、设备性能与配置1. **设备资源瓶颈**-检查路由器/交换机CPU/内存:```bashshowprocesses cpusorted#查看CPU占用最高的进程showmemory statistics```-关键阈值:-CPU持续>70%-内存使用率>80%2. **QoS策略冲突**-检查策略路由:```bashshowpolicy-mapinterface#查看QoS策略应用```-典型错误:-限速策略过严-优先级队列配置错误###六、高级诊断工具1.**主动探测工具**-`smokeping`:长期监控延迟和丢包- `netperf`:专业级网络性能测试2. **数据中心网络**-使用`perfSONAR`:跨域性能监测-光纤质量检测:OTDR测试仪(光衰减超标)###故障解决流程图```mermaidgraph TDA[发现丢包/高延迟]--> B{定位范围}B-->|单点问题| C[检查物理链路/网卡]B-->|局部网络| D[测试二层环路/广播风暴]B-->|全网问题| E[检查核心设备状态]C -->F{是否解决?}D -->FE--> FF -->|否| G[分段抓包分析]G -->H[检查TCP重传/MTU]H--> I{是否解决?}I -->|否| J[排查QoS/设备性能] ```###典型解决方案1. **物理层错误修复**:-更换损坏网线-调整网卡双工模式:```bashethtool-seth0speed1000duplex fullautonegoff#强制千兆全双工```2.**路由优化**:-调整OSPF/BGP成本值-启用ECMP(等价多路径)3. **拥塞控制**:-部署流量整形:```bash#LinuxTC示例tcqdiscadd deveth0root tbf rate100mbitburst1mbitlatency50ms```4.**MTU问题**:-在路由器上启用`ip tcp adjust-mss`-或手动设置客户端MTU:```bashifconfig eth0 mtu1400#Linuxnetshinterface ipv4set subinterface “Ethernet” mtu=1400# Windows``` ---###相关问题1.如何通过Wireshark分析TCP重传的具体原因?2.在无线网络中,如何区分信号干扰和带宽不足导致的丢包?3.如何利用BGP监控工具诊断跨国链路的延迟问题?4.数据中心RDMA网络丢包对性能的影响有何特殊性?5.网络拥塞控制算法(如BBR)如何改善高延迟链路的表现?</think>### 网络丢包和延迟问题排查与解决指南 #### **一、问题定位与基础测试** 1. **确定故障范围** - 测试不同目标地址: ```bash ping -c 100 8.8.8.8 # 测试公网地址 ping -c 100 192.168.1.1 # 测试网关 ping -c 100 同网段其他主机 # 测试局域网内通信 ``` - 关键指标分析: - 公网丢包→ISP链路或出口设备问题 - 网关丢包→本地网络问题 - 局域网丢包→物理层或二层故障 2. **持续监控工具** - 使用`mtr`(综合traceroute+ping): ```bash mtr -r -c 100 8.8.8.8 # 生成100个包的路径报告 ``` - 诊断要点: - 最后一跳丢包率>1%即异常[^1] - 中间节点丢包但目的节点正常→路径设备问题 #### **二、物理层与数据链路层排查** 1. **物理连接检测** - 网卡状态检查: ```bash ethtool eth0 # Linux(关注Speed/Duplex/Errors) Get-NetAdapterStatistics # Windows PowerShell ``` - 错误计数器分析: - `CRC errors`:线缆干扰或接口氧化 - `collisions`:半双工冲突(现代网络少见) - `overruns`:系统处理能力不足 2. **二层环路与广播风暴** - 交换机诊断: ```bash show interfaces | include errors|broadcast # 查看错误包和广播包 ``` - 风暴特征: - 端口广播包>10,000 pps - CPU利用率>90%且波动剧烈 - 解决方案: ```bash # 启用广播风暴控制 interface GigabitEthernet0/1 storm-control broadcast level 10 # 限制广播流量为10% ``` #### **三、网络层与路由分析** 1. **路径验证** - 路由追踪: ```bash traceroute -n 8.8.8.8 # 禁用DNS解析 ``` - 异常场景: - 路由循环→路由协议故障 - 非对称路径→策略路由配置错误 2. **MTU不匹配检测** - 测试方法: ```bash ping -s 1472 -M do 8.8.8.8 # Linux(1472+28=1500) ping -l 1472 -f 8.8.8.8 # Windows ``` - 症状:小包通,大包不通→MTU黑洞 - 解决: ```bash ifconfig eth0 mtu 1400 # 临时调整MTU ``` #### **四、传输层与拥塞控制** 1. **TCP性能分析** - Wireshark关键过滤: ```bash tcp.analysis.retransmission # 重传包 tcp.analysis.zero_window # 接收端拥塞 ``` - 重传率>1%需重点排查[^2] 2. **带宽拥塞测试** - iperf3压力测试: ```bash # 服务端 iperf3 -s # 客户端 iperf3 -c server_ip -t 30 -P 10 # 10个并行流 ``` - 判定标准: - 丢包伴随高抖动→线路质量差 - 丢包仅在高带宽时出现→带宽不足 #### **五、设备性能与配置** 1. **资源瓶颈检查** - 路由器/交换机诊断: ```bash show processes cpu sorted # CPU占用排序 show memory statistics # 内存分析 ``` - 危险阈值: - CPU持续>70% - 内存使用>80% 2. **QoS策略冲突** - 检测配置: ```bash show policy-map interface # 查看QoS应用 ``` - 典型错误: - 限速策略过严导致丢包 - 优先级队列配置错误 #### **六、高级诊断工具** | **工具** | **应用场景** | **关键命令/操作** | |----------------|----------------------------------|-----------------------------------| | **smokeping** | 长期延迟波动监控 | 配置多目标持续探测 | | **netperf** | 专业级TCP/UDP性能测试 | `netperf -H target -t TCP_STREAM` | | **perfSONAR** | 跨域网络性能分析(科研网常用) | 部署测量节点进行端到端测试 | | **OTDR测试仪** | 光纤质量检测(衰减>0.2dB/km异常)| 物理层故障定位 | ### 故障解决流程图 ```mermaid graph TD A[发现丢包/高延迟] --> B{定位范围} B -->|单点问题| C[检查物理链路/网卡] B -->|局部网络| D[测试二层环路/广播风暴] B -->|全网问题| E[检查核心设备状态] C --> F{是否解决?} D --> F E --> F F -->|否| G[分段抓包分析] G --> H[检查TCP重传/MTU] H --> I{是否解决?} I -->|否| J[排查QoS/设备性能] ``` ### 典型解决方案 1. **物理层故障**: ```bash # 更换损坏网线后测试 ethtool -s eth0 speed 1000 duplex full autoneg off # 强制千兆全双工 ``` 2. **路由优化**: ```bash # 调整OSPF成本值 router ospf 1 auto-cost reference-bandwidth 10000 # 万兆参考带宽 ``` 3. **拥塞控制**: ```bash # Linux流量整形 tc qdisc add dev eth0 root tbf rate 100mbit burst 1mbit latency 50ms ``` --- ### 相关问题 1. 如何通过Wireshark区分TCP重传与网络拥塞导致的丢包? 2. 在无线网络中如何精准定位信号干扰导致的延迟波动? 3. 如何利用BGP监控工具诊断跨国链路的丢包问题? 4. 数据中心RDMA网络丢包对性能的影响有何特殊性? 5. 网络拥塞控制算法(如BBR)如何优化高延迟链路?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值