作者：张医博
浅谈
本章节结合一些实际遇到的案例讲一下各种工具使用。
- 在遇到问题时先确保自己的工具一定是官方的最新迭代版本。
- 使用工具遇到问题时如果遇到 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
案例二：
排查：
如图用户在操作解冻文件的过程中出现 403，可能与两个原因有关系
- 用户使用的子账号操作文件，权限不够。
- 用户的文件是违禁内容被封禁掉了。
PS：遇到 403 时，递归解冻会中断不会继续。这种现象是正常的，工具在设计之初就是考虑到如果文件遇到 403 的话，代表没有权限操作该文件，那么通过该账号下的其他文件也操作不了，所以就会中断退出。
案例三：
排查：
检查用户的命令和官方提供的命令是否完全一致，避免误操作。
使用 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 内网是有阿里环网组成，如果客户只能在公网使用，进行下面的排查。
排查：
公网：
1） 首先看下用户端 ping OSS 的完整域名的网络 ping 值是否正常，tracert 是否有延迟抖动，此步骤可以通过脚本来做，下载脚本后运行，直接输入完整的 OSS 域名即可；脚本
- 脚本中是 ping 的是大包 1460，发现用户端直接网络超时，此时怀疑是客户的网络有限制或者网络拥塞，但是 tracert 通的，再进行下一步排查；
- 尝试降低 ping 包的 len 发现到 1412 ping 可以通过，说明客户端在网络上做限制，不允许 1460 大包的传输，影响了客户端的上行网络吞吐量；
2）尝试检查本机的网络负载；
- 通过本机资源监控看用户端当时的 CPU 负载和本机内存占用较高，实际登陆到客户端机器上发现系统卡顿，实际资源监控器看到 ossutil 工具线程并没有跑到和设置的 --job=10 --parallel=10 （10*10=100）一样，只是运行了 24 个，说明工具的线程受到了系统 CPU 调度影响，无法将网络吞吐打上去，于是让用户关系了一些占用 CPU 内存较高的应用后，ossutil 线程数终于打到 69；
- 调整前
调整后
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 。降低线程数，上传的效率也会受到影响；
