数据传输过程中丢包分析处理-原因可能是UDP或TCP缓存区满了导致

0.防火墙问题
如果系统是因为防火墙而丢包，表现的行为一般是所有的报文都无法正常接收,要排查的业务中只是部分相对少量丢包，认为非防火墙问题。（当然不排除防火墙只 drop 一部分报文的可能性。如果遇到丢包比率非常大的情况，防火墙某规则主动 drop UDP 报文）

 

1.检查阿里云SLB监控状态？
A、查看丢弃数据包数目？

发现为0,认为正常

B、检查丢弃连接数目？

发现为0.认为正常

 

2.命令检查每一台ECS,确认是否丢包
A、查看网卡丢包数据

命令 ifconfig eth0

查看显示结果中 errors 和 dropped 数目

errors 0  dropped 0

备注：如果硬件或者驱动没有问题，一般网卡丢包是因为设置的缓存区（ring buffer）太小

 

检查发现每一个节点errors和dropped查询值都为0,继续往下排查

 

B、检查报文数据

命令 netstat -s -u

发现其余节点都正常，但是有两台ECS表现如下

1、packet receive errors 不为空，并且在一直增长说明系统有 UDP 丢包

2、packets to unknown port received 表示系统接收到的 UDP 报文所在的目标端口没有应用在监听，一般是服务没有启动导致的

3、receive buffer errors 表示因为 UDP 的接收缓存太小导致丢包的数量

上述的表现中 UDP buffer size 不足

linux 系统在接收报文之后，会把报文保存到缓存区中。因为缓存区的大小是有限的，如果出现 UDP 报文过大（超过缓存区大小或者 MTU 大小）、接收到报文的速率太快，都可能导致 linux 因为缓存满而直接丢包的情况。

在系统层面，linux 设置了 receive buffer 可以配置的最大值，可以在下面的文件中查看，一般是 linux 在启动的时候会根据内存大小设置一个初始值。

/proc/sys/net/core/rmem_max：允许设置的 receive buffer 最大值

/proc/sys/net/core/rmem_default：默认使用的 receive buffer 值

/proc/sys/net/core/wmem_max：允许设置的 send buffer 最大值

/proc/sys/net/core/wmem_dafault：默认使用的 send buffer 最大值

但是这些初始值并不是为了应对大流量的 UDP 报文，如果应用程序接收和发送 UDP 报文非常多，把这个值调大。可以使用 sysctl 命令让它立即生效：

sysctl -w net.core.rmem_max=26214400 # 设置为 25M

也可以修改 /etc/sysctl.conf 中对应的参数在下次启动时让参数保持生效。

我们发现异常节点上 net.core.rmem_max  没有进行配置

而正常节点上

net.core.rmem_max = 10242880

我们直接把正常节点上的 /etc/sysctl.conf 所有配置参数直接复制到两个非正常的两个节点上。保证所有节点配置一致。

 

备注:  sysctl -a |grep net.core  查看参数设置

接收最大值设置

sysctl -w net.core.rmem_max=56214400 # 设置为 50M

接收默认值设置

sysctl -w net.core.rmem_default=26214400 # 设置为 25M

发送最大值

sysctl -w net.core.wmem_max=26214400 # 设置为 25M

发送默认值

sysctl -w net.core.wmem_default=26214400 # 设置为 25M

 

查看这个文件设置大小

vim /proc/sys/net/core/rmem_max

vim /proc/sys/net/core/rmem_default

vim /proc/sys/net/core/wmem_max

vim /proc/sys/net/core/wmem_default

 

C、应用丢包

上面提到系统的 UDP buffer size，调节的 sysctl 参数只是系统允许的最大值，每个应用程序在创建 socket 时需要设置自己 socket buffer size 的值。linux 系统会把接受到的报文放到 socket 的 buffer 中，应用程序从 buffer 中不断地读取报文。Netty中我们也会设置缓存区大小。其中 socket buffer size 大小以及应用程序读取报文的速度。receive buffer 会减少丢包的可能性，但同时会导致应用使用更多的内存，所以需要谨慎使用。另外一个因素是应用读取 buffer 中报文的速度，对于应用程序来说，处理报文应该采取异步的方式。

D、此外，要处理的实际业务中，每一个连接会占用一个句柄，测试有反馈有"Too many open files"的错误。这可能导致数据丢失而没有正确执行实际业务。

# ulimit -n  命令检查ECS后，有两台ECS句柄数目很小，是系统默认测数值65535。而其它ECS设置为

我们进行如下设置：

D1 修改文件：/etc/security/limits.conf

* soft nofile 165535#限制单个进程最大文件句柄数（到达此限制时系统报警）  

* hard nofile 165535#限制单个进程最大文件句柄数（到达此限制时系统报错） 

D2  运行命令：/sbin/sysctl -p 使配置生效

D3 对当前 session生效   

ulimit -n 165535

D4  备注:查看设置

ulimit -a

查看某个进程句柄数目

lsof -p 1296 | wc -l

经过上述设置后，后续再进一步继续观察监测，是否有数据丢失。