ossutil上傳性能調(diào)優(yōu) 的示例分析

今天就跟大家聊聊有關(guān)  ossutil上傳性能調(diào)優(yōu) 的示例分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

摘要： 經(jīng)常碰到內(nèi)部同學(xué)或者外部客戶問(wèn)ossutil關(guān)于并發(fā)上傳性能的問(wèn)題。本文簡(jiǎn)單描述下ossutil并發(fā)上傳原理并舉例說(shuō)明。 用戶可從這里獲取ossutil。  參數(shù) --recursive 上傳文件到oss時(shí)，如果file_url為目錄，則必須指定--recursive選項(xiàng)，否則無(wú)需指定--recursive選項(xiàng)。

經(jīng)常碰到內(nèi)部同學(xué)或者外部客戶問(wèn)ossutil關(guān)于并發(fā)上傳性能的問(wèn)題。本文簡(jiǎn)單描述下ossutil并發(fā)上傳原理并舉例說(shuō)明。

用戶可從這里獲取ossutil。

參數(shù)

--recursive

• 上傳文件到oss時(shí)，如果file_url為目錄，則必須指定--recursive選項(xiàng)，否則無(wú)需指定--recursive選項(xiàng)。

• 從oss下載或在oss間拷貝文件時(shí)

• 如果未指定--recursive選項(xiàng)，則認(rèn)為拷貝單個(gè)object，此時(shí)請(qǐng)確保src_url精確指定待拷貝的object，如果object不存在，則報(bào)錯(cuò)。

• 如果指定了--recursive選項(xiàng)，ossutil會(huì)對(duì)src_url進(jìn)行prefix匹配查找，對(duì)這些objects批量拷貝，如果拷貝失敗，已經(jīng)執(zhí)行的拷貝不會(huì)回退。

在進(jìn)行批量文件上傳（或下載、拷貝）時(shí)，如果其中某個(gè)文件操作失敗，ossutil不會(huì)退出，而是繼續(xù)進(jìn)行其他文件的上傳（或下載、拷貝）動(dòng)作，并將出錯(cuò)文件的錯(cuò)誤信息記錄到report文件中。成功上傳（或下載、拷貝）的文件信息將不會(huì)被記錄到report文件中。

批量操作出錯(cuò)時(shí)終止運(yùn)行的情況

• 如果未進(jìn)入批量文件迭代過(guò)程，錯(cuò)誤已經(jīng)發(fā)生，則不會(huì)產(chǎn)生report文件，ossutil會(huì)終止運(yùn)行。如，用戶輸入cp命令出錯(cuò)時(shí)，不會(huì)產(chǎn)生report文件，而是屏幕輸出錯(cuò)誤并退出。

• 如果批量操作過(guò)程某文件發(fā)生的錯(cuò)誤為：Bucket不存在、accessKeyID/accessKeySecret錯(cuò)誤造成的權(quán)限驗(yàn)證非法等錯(cuò)誤，ossutil會(huì)屏幕輸出錯(cuò)誤并退出。

report文件名為：ossutil_report_日期_時(shí)間.report。report文件是ossutil輸出文件的一種，被放置在ossutil的輸出目錄下，該目錄的路徑可以用配置文件中的outputDir選項(xiàng)或命令行--output-dir選項(xiàng)指定，如果未指定，會(huì)使用默認(rèn)的輸出目錄：當(dāng)前目錄下的ossutil_output目錄。

ossutil不做report文件的維護(hù)工作，請(qǐng)自行查看及清理用戶的report文件，避免產(chǎn)生過(guò)多的report文件。

并發(fā)控制參數(shù)

• --jobs選項(xiàng)控制多個(gè)文件上傳/下載/拷貝時(shí)，文件間啟動(dòng)的并發(fā)數(shù)

• --parallel控制上傳/下載/拷貝大文件時(shí)，分片間的并發(fā)數(shù)。

默認(rèn)情況下，ossutil會(huì)根據(jù)文件大小來(lái)計(jì)算parallel個(gè)數(shù)（該選項(xiàng)對(duì)于小文件不起作用，進(jìn)行分片上傳/下載/拷貝的大文件文件閾值可由--bigfile-threshold選項(xiàng)來(lái)控制），當(dāng)進(jìn)行批量大文件的上傳/下載/拷貝時(shí)，實(shí)際的并發(fā)數(shù)為jobs個(gè)數(shù)乘以parallel個(gè)數(shù)。該兩個(gè)選項(xiàng)可由用戶調(diào)整，當(dāng)ossutil自行設(shè)置的默認(rèn)并發(fā)達(dá)不到用戶的性能需求時(shí)，用戶可以自行調(diào)整該兩個(gè)選項(xiàng)來(lái)升降性能。

--part-size選項(xiàng)

該選項(xiàng)設(shè)置大文件分片上傳/下載/拷貝時(shí)，每個(gè)分片的大小。

默認(rèn)情況下，不需要設(shè)置該值，ossutil會(huì)根據(jù)文件大小自行決定分片大小和分片并發(fā)，當(dāng)用戶上傳/下載/拷貝性能達(dá)不到需求時(shí)，或有其他特殊需求時(shí)，可以設(shè)置這些選項(xiàng)。

如果設(shè)置了該選項(xiàng)（分片大小），分片個(gè)數(shù)為：向上取整（文件大小/分片大?。?，注意如果--parallel選項(xiàng)值大于分片個(gè)數(shù)，則多余的parallel不起作用，實(shí)際的并發(fā)數(shù)為分片個(gè)數(shù)。

如果將part size值設(shè)置得過(guò)小，可能會(huì)影響ossutil文件上傳/下載/拷貝的性能，設(shè)置得過(guò)大，會(huì)影響實(shí)際起作用的分片并發(fā)數(shù)，所以請(qǐng)合理設(shè)置part size選項(xiàng)值。

性能調(diào)優(yōu)

如果并發(fā)數(shù)調(diào)得太大，由于線程間資源切換及搶奪等，ossutil上傳/下載/拷貝性能可能會(huì)下降，所以請(qǐng)根據(jù)實(shí)際的機(jī)器情況調(diào)整這兩個(gè)選項(xiàng)的數(shù)值，如果要進(jìn)行壓測(cè)，可以一開(kāi)始將兩個(gè)數(shù)值調(diào)低，慢慢調(diào)大尋找最優(yōu)值。

如果--jobs選項(xiàng)和--parallel選項(xiàng)值太大，在機(jī)器資源有限的情況下，可能會(huì)因?yàn)榫W(wǎng)絡(luò)傳輸太慢，產(chǎn)生EOF錯(cuò)誤，這個(gè)時(shí)候請(qǐng)適當(dāng)降低--jobs選項(xiàng)和--parallel選項(xiàng)值。

如果文件數(shù)太多大小有不太平均，直接同時(shí)使用--jobs=3 --parallel=4進(jìn)行設(shè)定（文件間并發(fā)為3，單文件內(nèi)的并發(fā)為4），同時(shí)觀察MEM， CPU，網(wǎng)絡(luò)情況，若并未打滿網(wǎng)絡(luò)、占滿CPU，則可以繼續(xù)上調(diào)--jobs和--parallel。

真實(shí)案例

cdn.com/d05c9a5264819e0ef373602d64f5392f1d0e462d.png">

根據(jù)當(dāng)時(shí)客戶場(chǎng)景，下載速度大概在265M/s。

案例解析

在默認(rèn)情況下，因?yàn)槭嵌辔募螺d，所以會(huì)同時(shí)下載5個(gè)文件（version<=1.4.0，文件間的并發(fā)數(shù)為5）。

因?yàn)槠骄總€(gè)文件大小在1.1G，默認(rèn)會(huì)為每個(gè)下載的文件開(kāi)12個(gè)線程（單個(gè)文件內(nèi)的并發(fā)數(shù)為12，在沒(méi)有設(shè)置parallel參數(shù)和partsize參數(shù)時(shí)會(huì)根據(jù)文件大小計(jì)算出）。

那么在客戶的環(huán)境里ossutil在運(yùn)行期間至少有5*12= 60 個(gè)線程在跑。這么多并發(fā)應(yīng)該會(huì)直接打滿網(wǎng)卡，CPU應(yīng)該也很擁擠。建議在并發(fā)下載時(shí)觀察環(huán)境CPU，網(wǎng)絡(luò)，進(jìn)程/線程情況。

根據(jù)客戶的截圖，建議對(duì)每個(gè)文件分片100M~200M進(jìn)行并發(fā)，比如設(shè)為100M每個(gè)分片，這樣每個(gè)文件下載的并發(fā)數(shù)就是filesize/partsize。
ossutil cp oss://xxx xxx -r --part-size=102400000

如果文件數(shù)太多大小有不太平均，直接同時(shí)使用--jobs=3 --parallel=4進(jìn)行設(shè)定（文件間并發(fā)為3，單文件內(nèi)的并發(fā)為4）

總的建議就是：jobs * parallel 與CPU核數(shù)為1：1，2：1，但不要太大。

進(jìn)一步解釋

不是oss需要多少資源，是每個(gè)并發(fā)（讀取文件，分片，上傳等操作）所需的CPU，mem，網(wǎng)絡(luò)等。

• --jobs是多文件間的并發(fā)度，默認(rèn)是5（version <= 1.4.0，之后是3）

• --parallel是大文件內(nèi)部分片并發(fā)度，在沒(méi)有設(shè)置parallel參數(shù)和partsize參數(shù)時(shí)會(huì)根據(jù)文件大小計(jì)算出，最大不會(huì)超過(guò)15（version <= 1.4.0，之后是12）

• 如果文件數(shù)太多大小又不太平均，可以同時(shí)使用--jobs=3 --parallel=4進(jìn)行設(shè)定（文件間并發(fā)為3，單文件內(nèi)的并發(fā)為4，具體數(shù)字根據(jù)機(jī)器情況調(diào)整）

• cp默認(rèn)并發(fā)執(zhí)行，cp大文件用分片并發(fā)下載，小文件用put；默認(rèn)開(kāi)啟CRC校驗(yàn)。

• 在oss間拷貝文件，目前只支持拷貝object，不支持拷貝未complete的Multipart。

• 總的建議

• jobs * parallel 與CPU核數(shù)為1：1，2：1，但不要太大

• 并發(fā)數(shù)太多會(huì)直接打滿網(wǎng)卡，CPU也會(huì)擁擠。建議在并發(fā)時(shí)觀察環(huán)境CPU，網(wǎng)絡(luò)，進(jìn)程/線程情況

看完上述內(nèi)容，你們對(duì)  ossutil上傳性能調(diào)優(yōu) 的示例分析有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。