OSS 下载延迟或超时

  1. 云栖社区>
  2. 阿里云支持与服务>
  3. 博客>
  4. 正文

OSS 下载延迟或超时

张医博 2018-10-30 11:28:07 浏览2033

基础排查:

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

    ping -c 100 -i 0.01 -s 1024

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

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

1

2

分析:

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

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

1

分析:

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

案例:下载 socketTimeout

1

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

分析:

  • 先看下主机的 socket 资源是否足够分配,通过可以用 netstat 或者 ss 命令来查看本机的 socket 连接数,如果主机 TCP 占用较慢,很容易出现连接数资源不够分配的情况
    2
  • 看下主机的 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 产品,这种情况经常会遇到瓶颈,需要分开来看,如下图是我们总结一些常用的架构。

4

第一种架构:

  • 先确认访问到 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 下载慢

5

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

结论:

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