OSS 下载延迟或超时-阿里云开发者社区

开发者社区> 云服务技术课堂> 正文

OSS 下载延迟或超时

简介: DNS 解析不稳定导致 curl 延迟 分析: 通过上述信息基本可以判断是 DNS 问题,本次 curl 的时间都不稳定,加上 DNS 解析时间后,发现是卡在了 DNS 解析上,经过沟通发现阿里云的 DNS 223.5.5.5 在广东的节点已经撤销,建议使用运营商的 DNS 或者 114 的 DNS。

作者:张医博

基础排查:

  • ping 工具,目的测试到对端的 IP 链路是否有丢包,RTT(Round-Trip Time)是否有大的波动。详细命令

ping -c 100 -i 0.01 -s 1024

![1](https://yqfile.alicdn.com/a573e890357aee4205b86b68a1ce2cb431f8044f.jpeg)
  • mtr -n 通过 MTR 可以看到每一条的路由是否有丢包
    image.png
  • telnet 80 端口是否能通。保证 80 是通的才能下载
    image.png
  • 提供报错时的 OSS response header 中的 requestID 信息,一般 500 2XX 3XX 4XX 都会有 requestID 返回,504、502、503 这种网络超时的状态没有 requestID
    image.png

案例:DNS 解析不稳定导致 curl 延迟

image.png

image.png

分析:

通过上述信息基本可以判断是 DNS 问题,本次 curl 的时间都不稳定,加上 DNS 解析时间后,发现是卡在了 DNS 解析上,经过沟通发现阿里云的 DNS 223.5.5.5 在广东的节点已经撤销,建议使用运营商的 DNS 或者 114 的 DNS。

案例:本地机房下载 OSS 资源超时

image.png

分析:

  • 首先理清楚自己访问 OSS 架构是否是直接请求到 OSS 还是中间有 proxy 代理,如果有 proxy 代理的情况下先自己排查 client 到 proxy 的链路情况。
  • 自己先找个其他 region 的 bucket 看下是否能否复现问题,以此排除掉是不是 OSS 的问题。
  • 最好能够在客户端抓包分析一下,看看网络上卡在哪里导致的连接失败。

案例:下载 socketTimeout

image.png

常见于 SDK 、API 调用时的报错,客户源可能是在云主机或者 PC 端。通过文章开始所说道的信息我们判断是是否为必现问题,如果问题必现的话很容易能定位。如果不容易出现只能分层排查。

分析:

  • 先看下主机的 socket 资源是否足够分配,通过可以用 netstat 或者 ss 命令来查看本机的 socket 连接数,如果主机 TCP 占用较慢,很容易出现连接数资源不够分配的情况
    image.png
  • 看下主机的 ulimit -n 的文件描述符是否够用。
  • 如果用户使用的是 SDK ,需要确认 OSSClient 在初始化时是否限制了连接数和超时时间。如果通过前面测试发现网路不好抖动很大,建议把 sockettimeout 的时间放长些。
// 创建ClientConfiguration。ClientConfiguration是OSSClient的配置类,可配置代理、连接超时、最大连接数等参数。
ClientConfiguration conf = new ClientConfiguration();

// 设置OSSClient允许打开的最大HTTP连接数,默认为1024个。
conf.setMaxConnections(200);
// 设置Socket层传输数据的超时时间,默认为50000毫秒。
conf.setSocketTimeout(10000);
// 设置建立连接的超时时间,默认为50000毫秒。
conf.setConnectionTimeout(10000);
// 设置从连接池中获取连接的超时时间(单位:毫秒),默认不超时。
conf.setConnectionRequestTimeout(1000);
// 设置连接空闲超时时间。超时则关闭连接,默认为60000毫秒。
conf.setIdleConnectionTime(10000);
// 设置失败请求重试次数,默认为3次。
conf.setMaxErrorRetry(5);
// 设置是否支持将自定义域名作为Endpoint,默认支持。
conf.setSupportCname(true);


// 创建OSSClient实例。
OSSClient ossClient = new OSSClient(endpoint, accessKeyId, accessKeySecret, conf);

// 关闭OSSClient。
ossClient.shutdown();
一些特殊的架构场景,比如加了一些 proxy 产品,这种情况经常会遇到瓶颈,需要分开来看,如下图是我们总结一些常用的架构。

image.png

第一种架构:

  • 先确认访问到 CDN 的 URL 是否回到了 OSS ,还是直接访问 OSS 超时了。
  • 如果是访问 CDN 出现超时,需要确认是某个节点还是大面积节点出现问题。可以通过 17ce 这种批量测试网站检查下。
  • 如果是不同的 client 请求到同一个 CDN 节点超时,很可能 CDN 节点故障需要工单升级处理。
  • 如果是访问 CDN 正常,但是固定 OSS 源站出现超时,经过不同的客户端测试都能复现证明 OSS 确实出现问题,需要工单升级处理。
  • 如果访问 CDN 、OSS 都没有超时,很可能是 CDN 回 OSS 超时。这种回源链路超时,基本很难复现,需要升级工单快速跟进处理。

第二种架构

  • 还是一样的方法,先确认是访问 CDN 、waf 、OSS 哪个产品出现的超时。定位好环节后再进行分析。
  • 客户端有条件的情况下建议先查下到 WAF 的日志,或者 WAF 的回源日志确认下是否是 WAF 的问题导致超时。PS WAF 对回源 CDN 如果过于频繁会出现被拉黑的情况,目的是为了防攻击,如果出现回源 WAF 超时要升级工单确认下是否触发了防攻击的策略。

第三种架构

  • 与之前比较,多了一个 proxy 的转发在用户的业务 server 和 OSS 之间。这种情况先排查 server 到 proxy 之间的链路。
    • server- proxy 是否有链路抖动,ping MTR 结果都可以。
    • proxy 带宽是否有被打满。
    • proxy 是否有 NAT 的转换导致 OSS 建立连接 session 混乱。
    • proxy 到 OSS 的链路,可以通过 ping MTR 测试。

案例:通过内网地址 wget 下载慢

image.png

  • 如果 type 类型是 normal / multipart 文件读取数据是多线程的,一般情况下不会慢,如果慢的话,需要提供 requestID 升级阿里云查询下。
  • 如果是 append 文件读取速度是单线程的,符合预期。

结论:

append 类型的文件是追加写,wget 下载时,服务端的 read 是单线程,所以速度提不上去。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

云服务技术课堂,各类技术课程、最佳实践输出,来好好听课吧!

官方博客