性能文章>性能测试之文件上传的瓶颈分析调优>

性能测试之文件上传的瓶颈分析调优原创

9月前
245689

问题反馈

这是一个给第三方压测之后,第三方反馈的性能问题。
大致描述如下:并发上传 10 个文件的时候,接口完全没有响应,通过看服务器日志发现,请求根本没有到服务端,直接被某个地方拦截了。

按道理来说,10 个并发数量不是很大,jmeter 不会卡住的,于是让他们排查线程池队列,nginx 队列,mysql 队列,都没有发现问题

一的问题是这十个文件都比较大,大约是 14 兆左右的 pdf 文件。同时上传可能会对网络有影响。于是排查一下网络环境,看看有没有丢包,监听了一会,发现根本没有网络流量,所以不存在丢包坏包等现象。

纠结了一会,一筹莫展,连运维都一起拉进来研究这个问题

正在没头绪的时候,突然想到看一下日志,于是实时打印了一下设备日志,发现了一条奇怪的日志

watch "dmesg | tail -20"

感觉是 gro 导致的 tcp 异常,看到 GRO,就突然想起了一个熟悉的词mtu。这两个有什么关联?

mtu

mtu 是最大传输单元
如果 I P 层有一个数据包要发送,而且数据的长度比 M T U 值还大,那么 I P 层就需要对数据进行切片,把数据包分成若干片,这样每一片都小于 M T U 值

GRO

现在网卡都有 LRO/GRO 功能。网卡收包时将小包合并成大包,然后交给内核协议栈。LVS 内核模块在处理>MTU 的数据包时,会主动丢弃。
因此,如果我们用 LVS 来传输大文件的时候传输速度会极其慢。
/sbin/ethtool -k eth0 |grep offload 查看 gro 是否打开,发现果然是打开的。

我的思路是,要么把 gro 关了,要么把 mtu 加大。考虑到机器还有别的用户,关闭 gro 可能会有其它影响,于是就决定把 mtu 放大到 4000

mtu 默认值是 1500

修改到 4000
echo "4000" > /sys/class/net/ens192/mtu
结果显而易见,请求过去了

结尾语

问题的解决思路就在于日志,以及平时的一些经验积累,看到 gro 就想到了 mtu,继而就想到了可能是文件过大导致的切片失败。
点赞收藏
飞天小子

13软件测试,10年性能测试,5年性能培训,10万字性能博主,项目经理,微信uhz2008

请先登录,查看8条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步
9
8