浅谈
本章节结合一些实际遇到的案例讲一下各种工具使用。
- 在遇到问题时先确保自己的工具一定是官方的最新迭代版本。
- 使用工具遇到问题时如果遇到 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 。降低线程数，上传的效率也会受到影响；
