运维坑记录（一）-GRO功能导致LVS变慢在Centos6（2.6.29-2.6.39）下，如果开启GRO，LVS会丢很多包。1问题现象线上服务器使用LVS做负载均衡和高可用，LVS使用DR模式。使用新的LVS后，发现上传数据的时候，小数据会很快，大数据会很慢。如果绕过LVS，直接走后端，就没有这个问题，所以问题出在了LVS所在的服务器上。现将测试环境复现如下。上传两个文件，一个10k，一个100k，10k只需要0.009秒，100k将近10秒：[root@chengqmtest_upload]#ll-htotal112K-rw-r--r--.1rootroot100KMar3121:26100k_file-rw-r--r--。1rootroot10KMar3121:2510k_file[root@chengqmtest_upload]#timecurl10.0.1.188:22333/upload-F"myfile=@./10k_file"okreal0m0.009suser0m0.001ssys0m0.003s[root@chengqmtest_upload]#timecurl10.0.1.188:22333/upload-F"myfile=@./100k_file"okreal0m9.785suser0m0.000ssys0m0.006s2位置原因在lvs服务器上执行tcpdumphost10.0.1.188-wlvs.pcap捕获数据包并使用Wireshark打开它们。发现有大量重传和Fragmentationneeded控制报文需要分片。然后使用netstat-i查看Client的MTU和LVS网卡是否一致，发现相关服务器的MTU值是1500，网络工程师通知网络设备MTU没有改变，并且排除机器MTU不一致导致的问题。搜索关键字lvsfragmentationneeded，发现一个叫做GRO的函数可能会导致LVS机器丢包。使用ethtool-k网卡名称查看网卡配置。对比正常的LVS网卡，发现问题网卡确实开启了GRO功能[root@chengqm-lvs~]#ethtool-keth0|grep'generic-receive-offload'generic-receive-offload:on手动关闭GRO功能[root@chengqm-lvs~]#ethtool-Keth0grooff再次上传数据[root@chengqmtest_upload]#timecurl10.0.1.188:22333/upload-F"myfile=@./100k_file"okreal0m0.031suser0m0.001ssys0m0.009s问题解决，恢复正常超过MTU的数据包会被分片。对于目前的网卡性能来说，这个值太小了。现在普遍使用10Gbps的网卡。如果10Gbps网卡满载，一个完整的数据包就是Shard800w个切片。我们可以通过修改MTU来减少分片，但是修改MTU涉??及的设备太多，不可控。于是就有了通过网卡间接增加MTU的解决方案，就是GRO。如果启用GRO，网卡中满足一定条件的数据包将被组装并合并成分片数据包，然后一次性传递给上层协议栈。2.6.29之后，如果网卡和驱动都支持的话，GRO功能会默认开启。据说在2.6.29-2.6.39版本中，当LVS内核模块处理>MTU包时，会丢弃，所以可以看到一堆重传包，需要分片。4有没有其他办法调整相关设备的MTU值。升级安装了LVS的机器的系统内核。本着先恢复正常使用的原则，我们直接关闭了GRO。以上两种方案都可以作为后续调整的方向。方案一涉及设备较多，风险和影响难以评估，暂不考虑。方案2可以作为后期的调整方向。需要注意的一点是，如果你使用的是云服务器，需要同时关闭宿主机的GRO。如果绑定了网卡，需要关闭真实网卡中的GRO。通用接收offloadlvs：需要GRO/icmp碎片的问题
