OSS-ossutil-阿里云开发者社区

开发者社区> 阿里云支持与服务> 正文

OSS-ossutil

简介: 案例:访问 403 deny 分析: 类这种有明显报错的很好判断,明显是 endpoint 指定错误。 bucket 和 endpoint 不匹配 bucket UID 和实际的 Accesskey 对应的 UID 不一致

浅谈

本章节结合一些实际遇到的案例讲一下各种工具使用。

  • 在遇到问题时先确保自己的工具一定是官方的最新迭代版本。
  • 使用工具遇到问题时如果遇到 4xx 3xx 2xx 500 等问题,oss 都会返回一个 x-oss-requestID 的 http 头,value 是一串字符,类似 5BEE7AD4C84D1C447120083C 这个对于排查分析问题非常重要。
  • 每个工具基本都带有 log 功能,请使用者务必开启,遇到问题时可以追根溯源。

使用场景

  • ossutil 专司于高并发大文件或小文件读写的场景,同时支持大文件内部进行分片时的并发;
  • 操作文件时可以支持 include exinclude 参数,指定哪些后缀的文件可被操作;
  • 只显示当前的层级的目录,可选择性的进行递归;
  • 伴随 Linux 系统本身的 crontab 使用支持,强制更新 -f -u 参数;
  • 限制 ossutil 的操作速度;

案例一:

ossutil 出现 skip 情况

[root@iZ2Sv4olcc4Z opt]# echo “testlil” >  dskydb/test.txt
[root@iZ25v4olcc4Z opt]# ./ossutil64 cp -rt -c ~/.ossuti.Lcofig dskyclb/test.txt oss://gres/test.txt
Succeed: Total nun: 1, $ze: 30. OK nun: 1(upload 1 files).
0.372650(s) elapsed I
[root@iZ2Sv4olcc4Z opt] echo " ttest222r" >> dskydb/test.txt
[root@iZ2Sv4olcc4Z opt]. /ossutil64 cp —u —c ~/.ossutilconfig cbkydb/test.txt oss://gres/test.txt
Succeed: Total num: 1, ize: 38. OK nun: l(skip 1 files), Skip sin 38.
0.252878(s) elapsed

排查:

1)使用 -u 强制更新时,重新对所有的上传文件和原的进行一次比对,发现美有更改的情况就会跳过,有发生更改的就会触发上传进行覆,正常情况。

2)遇到这种情况可以看下本地的 log 哪些文件被跳过了,将 oss 存储的文件和本地文件做个 MD5 比对确保文件是一致。

3)命令:./ossutil64 cp -u -r -f aa.test oss://alihua -i -k -e

案例二:

1

排查:

如图用户在操作解冻文件的过程中出现 403,可能与两个原因有关系

  • 用户使用的子账号操作文件,权限不够。
  • 用户的文件是违禁内容被封禁掉了。

PS:遇到 403 时,递归解冻会中断不会继续。这种现象是正常的,工具在设计之初就是考虑到如果文件遇到 403 的话,代表没有权限操作该文件,那么通过该账号下的其他文件也操作不了,所以就会中断退出。

案例三:

2

排查:

  • 检查用户的命令和官方提供的命令是否完全一致,避免误操作。
  • 使用 stat 选项看一下文件的状态是否是已经解冻了,如果以及解冻再次操作,就会出现 400。

案例四:

ossutil 操作 object 出现 “The operation is not valid for the object's state”

排查:

出现这个问题是因为用户操作的文件是一个归档的文件,不能直接操作,需要先进行解冻 restore 的操作后才能使用。

  • ossuti64 restore oss://bucket/prefix/object -I <accesskey> -k <secretkey> -e <endpoint>

递归解冻

  • ossuti64 restore oss://bucket/prefix/ -r -I <accesskey> -k <secretkey> -e <endpoint>

案例五:

ossutil 挂载 crontab 中执行报错

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x6b4981]

goroutine 1 [running]:
github.com/aliyun/ossutil/lib.DecideConfigFile(0x0, 0x0, 0x7a8017, 0x7)
  /Users/fengyu/go/src/github.com/aliyun/ossutil/lib/config_helper.go:57 +0x51

排查:

请直接下载 ossutil 的工具最近版本进行处理。这个问题已经解决掉。

案例六:

Windows ossutil 上传 OSS 速率慢不稳定,客户端是在河北公网,目标服务端是北京,存在跨省情况;
首先了解下用户在公网情况下,能否切换到同 region 的 OSS 上进行访问,同 region 的 OSS 内网是有阿里环网组成,如果客户只能在公网使用,进行下面的排查。

image

排查:

公网:

1) 首先看下用户端 ping OSS 的完整域名的网络 ping 值是否正常,tracert 是否有延迟抖动,此步骤可以通过脚本来做,下载脚本后运行,直接输入完整的 OSS 域名即可;脚本

  • 脚本中是 ping 的是大包 1460,发现用户端直接网络超时,此时怀疑是客户的网络有限制或者网络拥塞,但是 tracert 通的,再进行下一步排查;
    image
  • 尝试降低 ping 包的 len 发现到 1412 ping 可以通过,说明客户端在网络上做限制,不允许 1460 大包的传输,影响了客户端的上行网络吞吐量;
    image

2)尝试检查本机的网络负载;

  • 通过本机资源监控看用户端当时的 CPU 负载和本机内存占用较高,实际登陆到客户端机器上发现系统卡顿,实际资源监控器看到 ossutil 工具线程并没有跑到和设置的 --job=10 --parallel=10 (10*10=100)一样,只是运行了 24 个,说明工具的线程受到了系统 CPU 调度影响,无法将网络吞吐打上去,于是让用户关系了一些占用 CPU 内存较高的应用后,ossutil 线程数终于打到 69;
  • 调整前
    image
  • 调整后
    image

3)灵活调整 ossutil 的线程数和分片的并发数;

--bigfile-threshold=52428800 --jobs=10 --parallel=50 --part-size=52428800

  • 遇到大文件数量多,以及单一的大文件时我们要灵活调整 ossutil 的相关参数能够提高我们的 ossutil 的效率;
  • 比如这个案例中客户的文件大小平均是 100M 以上,而且客户的出口带宽是共享 200M ,也就是客户自己的上线速度理论上也要 20M;
  • 针对这种情况,我们可以把分片大小调整为 50M-10M,同时增加 parallel 分片的并发数量,尽可能的打满上行的吞吐。当客户端 CPU 核心比较少的时候不建议分的太小,比如分到 1M 时就会造成 CPU 切片过快,消耗 CPU 计算,影响系统性能。
  • 如果遇到文件数量单一大文件,或者小文件时,可以不用加任何参数,直接上传即可;调整完成后用户的上行出口速率能打到 10M 大 B。

4)对比其他家的工具

  • 比如七牛的 qfetch 以及 qshell 做了性能对比,上行的传输效率相差并不多,并没有用户反馈了七牛 20M (大B)阿里云 4M(大B),基本上qshell 和 qfetch 的效果都是稳定在 10M 左右;

总结下问题以及需要客户下一步解决:

当使用 ossbrower 上传速度低时可以切换到 ossutil 这个高兴的工具进行测试;
需要用户解决下为什么网络出口限制的大包(1460) 的传输,这个问题不解决很难将网络带宽吞吐提上去。
尽量本机不要在负载高的情况下上传一些大文件,如果传输的话可以关闭一些应用卡顿的程序,或者降低下 ossutil 工具的并发线程数量,不然即使设置了 100 ,但实际受到系统的 CPU 调用影响,不一定能跑到 100 。降低线程数,上传的效率也会受到影响;

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

分享:

分享阿里云支持与服务团队最佳实践、经典案例与故障排查。

官方博客
文档