【 OSS 排查方案-9 上传 OSS 延迟超时】

基础排查

一、

上传 OSS 出现慢的场景,OSS 会返回一个 requestID 属性,请保留这个 requestID 这是 OSS 所有信息的查询入口,升级阿里云时可以快速定位问题,如果上传超时的话时没有这个属性的。 requestID 可以通过抓包获取到,也可以在代码中解析 OSS 的返回 http result 结果获得。

【 OSS 排查方案-9 上传 OSS 延迟超时】

二、

客户端在上传 OSS 时用的内网的地址还是公网的 OSS 地址,如果使用了阿里云主机服务,并且和 OSS 是同一个 region ,强烈推荐使用 internal 内网地址操作 OSS 这能大大提升你的请求速度。OSS 提供的域名可以参考
https://help.aliyun.com/document_detail/31837.html?spm=a2c4g.11186623.6.571.4dcd2841C29fHi

三、

如果走公网上传 OSS ,速度无法保证,排查需要结合多个网络测试命令,比如常用
ping -c 50 -i 0.01 -s 1024 <OSS 公网域名>
mar <OSS 公网域名>
traceroute <OSS 公网域名> ,如下测试客户端的网络出口也不是很稳定,需要多次的测试。

【 OSS 排查方案-9 上传 OSS 延迟超时】

四、

排除客户端出口带宽是否被打满,可以通过 iftop 看下客户端的出口流量。

五、

etstat 查看下主机的 TCP 链接是否被打高

六、

客户端的上传代码读取的是本地文件还是网络流,如果是读取的网络流然后上传到 OSS ,那读文件的时间也会影响到上传时间。建议用本地文件先测试。

七、

客户端的代码是否开启过 crc64 ,开启这个功能对上传的性能影响比较大,开启 crc 后,要在本地先对文件循环冗余校验完后,在开始上传,很消耗性能。

"看病" 对号入座,按照上面描述的分成多个问题进行描述,基本都是上传延迟的问题。

案例:开启 crc64 上传速度下降

【 OSS 排查方案-9 上传 OSS 延迟超时】

该病例,使用 ossutil 工具对比 OSS 的 SDK 上传速度比 osstuil 慢几十倍。

  • 通过截图也能看出来确实慢,但是 SDK 即使代码写的再差也不能如此地步。
  • 翻阅代码中发现 OSS SDK 在初始化 ossclient 时开启了 crc64 ,关闭后性能直线上升,回复到正常状态,秒传。
auth = oss2.Auth('AK', 'SK')
bucket = oss2.Bucket(auth, 'endpoint', 'bucket',enable_crc=False)

【 OSS 排查方案-9 上传 OSS 延迟超时】

结论:
如果使用 OSS SDK 时建议关闭掉 crc64 ,可以在请求头中增加 Content-MD5 的方式用 MD5 替换 crc64 ,性能更快。

案例:调用 JAVA SDK 上传打印出的时间判断处理很慢

分析:
通过 JAVA 2.8.3 版本的上传接口 PutObjectResult putObject(String bucketName, String key, InputStream input) 上传文件到 OSS ,通过打印前后的系统时间发现每次上传都要几十秒,但是通过 requestID 和抓包的结果都很快。

【 OSS 排查方案-9 上传 OSS 延迟超时】

通过完成的抓包,可以看到网络传输开始到结束的时间非常短,物理的传输时间都很短,证明确实很快就完成上传的操作,但为什么打印的时间差和抓包有这么大差距,需要看下客户端的代码。发现客户端的代码再调用 putobject 时传入的文件是一个网络流,通过公网去读源文件,代码 debug 发现时间整体卡在了读的延迟上,于是更换了本地文件测试后发现秒传。

结论:
建议出现这类问题先抓包看下实际的物理传输是不是真的慢,还仅是自己打印的时间慢而已。

案例:教学作业大量上传超时

分析:

第一个问题:客户端时再内蒙古,OSS 再杭州,通过公网上传 OSS,在学校内部上传作业失败率很高,但是在校外上传失败率明显下降。日志报链接失败。

ossupload by all localcatch, filepath:/storage/emued/0/Homrk/com.identhomework/temp0/1539238757673.JPEG,ex:Failed to connect to /124.160.145.44:80
[ErrorMessage]: Failed to connect to /124.160.145.44:80,time:2018-10-11 14:56   

第二个问题:客户端网络内无法解析公网域名。

【 OSS 排查方案-9 上传 OSS 延迟超时】

第二个问题比较好解决,客户端的 DNS 服务出现问题导致解析失败,或者 DNS 请求超时无法解析出域名。第一个问题我们就要用上述的基础排查一步步看

  • 排查到 ping 时就发现客户端的网络比较差,丢包率达到了 6% ,这种问题肯定需要在客户端进行抓包分析。
    【 OSS 排查方案-9 上传 OSS 延迟超时】
  • 通过抓包发现客户端的网络丢包很高,同时出现了很多乱序,只截图了部分的抓包信息。通常都知道少量的乱序没有关系,但是大量的乱序报文会造成重传,而且频繁的丢包,也会导致不停的重传。
    【 OSS 排查方案-9 上传 OSS 延迟超时】

结论:
综合现象来看当客户端由学校转移到家里后失败率就下降,学校的网络避免不了嫌疑,但是由于一致没有抓包链接失败的包,只能从网络的角度分析,客户端的弱网导致了链接失败超时。此类问题只能通过抓现象包来进行分析,遇到这类问题第一时间抓包保留现场。

案例: PutObject 写入超时

【 OSS 排查方案-9 上传 OSS 延迟超时】

分析:

  • 客户端时用的 webDav 工具上传到 OSS ,上传时会直接出现机器负载高的情况。这种情况可以先使用阿里云的 ossutil 工具,这个性能非常好,支持并发、断点、分片上传。https://help.aliyun.com/document_detail/44075.html?spm=a2c4g.11174283.6.1256.18687da2tNqG1T
  • 如果替换 ossutil 还出现上传 502 的话,就必须要在客户端抓包分析,在此之前先将文章开始的基础排查做一遍。`

案例:跨国传输链接超时

【 OSS 排查方案-9 上传 OSS 延迟超时】

出现这种跨国传输超时,要先在本地抓包,判断是否被国际链路出口封堵导致,一般跨国的 OSS 传输建议购买全球加速 CDN 的方式来做,或者使用阿里云的高速通道和专线。

案例:客户端突发大量上传时间过长

【 OSS 排查方案-9 上传 OSS 延迟超时】

分析:

客户端先尝试开始的基础排查,先确定客户端的网络是稳定的,如果无法解决后,第一时间获取到上传时间过长的 requestID 或者抓包升级到阿里云。

案例:SDK 上传打印时间很长

【 OSS 排查方案-9 上传 OSS 延迟超时】

【 OSS 排查方案-9 上传 OSS 延迟超时】

通过 SDK 上传小文件到 OSS ,自己代码中调用时间打印发现超过 20s

分析:

出现这种问题,先在本地部署个抓包看下是否真的上传有延迟,该案例是程序问题, SDK 再读取文件是通过网络流读取,这部分时间也算到 SDK 的上传时间内。导致打印的时间过长,切换到本地文件测试后时间恢复正常。

案例:Node.js 上传超时 socketTimeout

2018-10-26 10:06:05.962 nodejs.ResponseErrorException: ResponseError: socket hang up, GET http://prod33.vpc100-oss-cn-beijing.aliyuncs.com/webpack-hot-middleware/-/webpack-hot-middleware-2.24.3.tgz -1 (connected: true, keepalive socket: true, agent status: {"createSocketCount":3436,"createSocketErrorCount":0,"closeSocketCount":3433,"errorSocketCount":0,"timeoutSocketCount":58,"requestCount":3520,"freeSockets":{},"sockets":{"prod33.vpc100-oss-cn-beijing.aliyuncs.com:80:":3},"requests":{}}, socketHandledRequests: 2, socketHandledResponses: 1)
headers: {}

2018-10-26 10:46:15.042 nodejs.ResponseErrorException: ResponseError: socket hang up, GET http://pro-rd-cnpm.vpc100-oss-cn-beijing.aliyuncs.com/is-binary-path/-/is-binary-path-1.0.1.tgz -1 (connected: true, keepalive socket: true, agent status: {"createSocketCount":633,"createSocketErrorCount":0,"closeSocketCount":632,"errorSocketCount":0,"timeoutSocketCount":1,"requestCount":632,"freeSockets":{},"sockets":{"pro-rd-cnpm.vpc100-oss-cn-beijing.aliyuncs.com:80:":1},"requests":{}}, socketHandledRequests: 2, socketHandledResponses: 1)

2018-10-26 10:46:15.042 nodejs.ResponseErrorException: ResponseError: socket hang up, GET http://pro-rd-cnpm.vpc100-oss-cn-beijing.aliyuncs.com/is-binary-path/-/is-binary-path-1.0.1.tgz -1 (connected: true, keepalive socket: true, agent status: {"createSocketCount":633,"createSocketErrorCount":0,"closeSocketCount":632,"errorSocketCount":0,"timeoutSocketCount":1,"requestCount":632,"freeSockets":{},"sockets":{"pro-rd-cnpm.vpc100-oss-cn-beijing.aliyuncs.com:80:":1},"requests":{}}, socketHandledRequests: 2, socketHandledResponses: 1)
headers: {}

【 OSS 排查方案-9 上传 OSS 延迟超时】

分析:

  • 通过初始的报错信息可以知道客户端是 socket 建联失败导超时断开,请求没有到 OSS ,提供的日志表象可以看出请求并发越高,本地的 socket 超时越多,由此判断是客户的并发高导致出现了瓶颈引起的 socket 超时。
  • 通过辅助的抓包发现,客户端是 keepalive + 高并发的场景,如果客户端长期不释放掉 TCP 链接书,很容易将客户端的协议栈打满,造成 socket 建联超时。

结论:

  • 自己的程序代码中,将 keepalive 请求缩短,并且客户端的程序中要在请求完成后主动示范掉长链接回收资源。
  • ss -la | grep -i wait 看下并发高的时候主机的 wait 数量是不是很高,如果大量的 wait 无法释放也回占用主机的资源。
  • ss 看下主机的链接数有没有超时 ulimit 的限制。
  • 并发高的时间,主机出口带宽是否被占满。
  • 程序上建议增加一个 sockettimeout 的容错,设置合理的间隔时间然后重试下。

案例:解析失败导致超时

2018/10/24 14:03:47 hlg_matting_PreF (pid=15693)(error): parseUrl2Image.hpp(186), read_element: image_url_service connect fail: Could not resolve host: disanzhe.oss-cn-hangzhou-internal.aliyuncs.com, url: https://disanzhe.oss-cn-hangzhou-internal.aliyuncs.com/mattings/0/images/20181024-135354-f5ee.jpg

通过报错可以看出客户端发出的 DNS 请求都失败,导致的请求 OSS 超时,这种问题,直接看下 DNS 服务是否异常,或者 DNS 出现异常、限流等问题,并不是 OSS 故障。

案例:驻云客户端上传 OSS 错误

【 OSS 排查方案-9 上传 OSS 延迟超时】

问题:

客户端通过驻云工具上传 OSS 同一个 bucket 不通 prefix,经常出现 curl error 的情况,由于驻云客户端不是阿里云开发的,所以错误定义并不是很清晰,逐一排查。

分析:

  • 看下客户端工具的并发线程设置。
  • 客户端的出口带宽是否有限制。
  • 替换下 OSS 可靠的工具 ossutil,或者 ossbrower 再测试一下。
    结果替换为 ossbrower 文件可以正常上传。
上一篇:ntp时间同步返回“no server suitable for synchromization found”的排查


下一篇:Jpom一款简而轻的低侵入式Java运维、监控软件