OSS-ossutil

作者：張醫博

淺談

本章節結合一些實際遇到的案例講一下各種工具使用。

• 在遇到問題時先確定自己的工具一定是官方的最新疊代版本。
• 使用工具遇到問題時如果遇到 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 。降低線程數，上傳的效率也會受到影響；