使用ossfs 2.0與OSS(Object Storage Service)互動時,合理最佳化發往OSS服務端的中繼資料請求量,不僅能減少OSS請求以節省服務調用成本,還能提升系統並發處理能力,同時改善掛載點的讀寫效能。
基本原理
ossfs 2.0基於FUSE(Filesystem in Userspace)架構進行開發,可以將檔案系統的中繼資料操作介面,轉換為對應的OSS請求,從而實現通過檔案系統的操作方式訪問OSS儲存資源。
命令 | 介面轉換規則 |
| 當執行 若GetObjectMeta請求返回404響應(表示對象不存在),則進一步發送ListObject(max-keys=1)請求,以查詢是否存在同名的虛擬資料夾對象。 |
| |
| 執行 需注意,ossfs 2.0預設啟用 |
|
情境解析
在檔案系統中訪問一個檔案與在OSS中訪問一個同名對象存在以下顯著差異:
檔案訪問方式
ossfs 2.0採用從根目錄逐級向下的訪問方式訪問檔案,以擷取位於/dir/object路徑下object檔案的屬性資訊為例,使用stat /dir/object命令執行流程如下:
首先對/dir執行操作,發送GetObjectMeta dir請求,若返回404 Not Found則表明該對象不存在,繼而發送ListObject (max-keys=1)dir/請求,若返回200 OK,則說明存在對應的虛擬資料夾。
對/dir/object執行操作,發送GetObjectMeta dir/object請求,若返回200 OK,則成功擷取到對象屬性資訊。
綜上分析可得,單次stat /dir/object命令執行,最終轉換為兩次GetObjectMeta請求與一次ListObject請求。並且檔案系統的中繼資料請求會轉換為多個OSS請求,且隨檔案的深度增長而增長,造成效能大幅下降。
檔案中繼資料快取影響
ossfs 2.0預設開啟檔案中繼資料快取,且中繼資料快取預設失效時間為60秒。中繼資料快取的緩衝容量基於FUSE low-level API進行實現,由作業系統核心決定何時淘汰,記憶體較多的機器通常可以緩衝更多的中繼資料資訊。
以擷取位於/dir/目錄下100個子檔案的屬性資訊為例,說明檔案中繼資料快取對效能的影響。
未開啟中繼資料快取
已知檔案清單訪問檔案:
迴圈執行
stat /dir/object-<i>命令,每一次stat操作都將轉換為一次GetObjectMeta請求,最終產生100次GetObjectMeta請求發送到OSS以擷取檔案屬性,從而導致中繼資料請求次數過多影響效能。未知檔案清單訪問檔案:
執行
ls命令,該操作將轉換為一次ListObject請求發送到OSS以擷取檔案清單,再通過擷取到的檔案清單迴圈執行stat /dir/object-<i>命令擷取檔案屬性,最終將產生一次ListObject請求和100次GetObjectMeta請求發送至OSS,從而導致中繼資料請求次數過多影響效能。
開啟中繼資料快取
已知檔案清單訪問檔案:
迴圈執行
stat /dir/object-<i>命令,每一次stat操作都將轉換為一次GetObjectMeta請求,最終產生100次GetObjectMeta請求。這100次請求在中繼資料快取有效期間內會直接命中本地中繼資料快取擷取檔案屬性,從而有效減少發送至OSS的請求次數。未知檔案清單訪問檔案:
執行
ls命令,該操作將轉換為一次ListObject請求發送至OSS同時更新本地中繼資料快取。在完成緩衝更新後,再迴圈執行stat /dir/object-<i>命令,由於此時中繼資料已在本機快取中,將不會發送額外的OSS請求。
綜上分析可得,中繼資料快取機制可以有效減少重複發送到OSS的請求次數,若要遍曆訪問某個檔案夾下的所有檔案時,通過ls可以提前預載中繼資料快取,從而有效減少後續對子檔案的OSS請求。
最佳化方式
通過以下方式減少發送至OSS的中繼資料請求從而提升整體效能:
延長中繼資料快取時間
如果讀取的資料一旦上傳到OSS中就不會修改,或修改時間間隔遠大於中繼資料快取時間,可通過attr_timeout掛載選項配置更長的中繼資料快取失效時間,從而減少重複的中繼資料請求以提升效能。掛載選項配置樣本如下。
業務情境:在資料標註情境中,系統會讀取預先收集的一批未經處理資料,經處理後再產生一批新資料。此情境下未經處理資料一旦上傳至OSS就不會修改。
掛載配置:在ossfs 2.0設定檔中,配置中繼資料快取失效時間為7200秒。
# Bucket所處Endpoint(地區節點) --oss_endpoint=https://oss-cn-hangzhou-internal.aliyuncs.com # Bucket名稱 --oss_bucket=bucketName # 中繼資料快取失效時間 --attr_timeout=7200 # 存取金鑰AccessKey ID和AccessKey Secret(ossfs 2.0.1及後續版本該配置項可選) --oss_access_key_id=LTAI****************** --oss_access_key_secret=8CE4**********************
擷取檔案清單後操作
在遍曆訪問某個目錄下的所有檔案時,可先通過ls命令或發送ListObject請求,將目標檔案夾下所有檔案的中繼資料提前載入至本地中繼資料快取,同時配合較長的緩衝失效時間,以此減少重複的中繼資料請求,最終實現整體效能的提升。
ls命令可替換為任意用於讀取檔案夾內容的進階語言程式。以擷取/mnt/data/目錄下檔案清單為例,常見樣本如下。
Python
os.listdir('/mnt/data/')Go
entries, err := os.ReadDir("/mnt/data/")C
dir = opendir("/mnt/data/");
if (dir != NULL) {
struct dirent *entry;
while((entry = readdir(dir)) != NULL) {}
closedir(dir);
}使用negative緩衝加速檔案建立速度
檔案系統在建立新檔案時,會依次執行lookup + create兩次系統調用:
使用
lookup來查詢對應檔案是否存在,在ossfs 2.0中會被解析成GetObjectMeta + ListObjects請求。若返回404不存在,則使用
create來建立對應檔案,在ossfs 2.0中執行create時也需要發送GetObjectMeta + ListObjects請求來查詢OSS中是否存在該檔案。
故一次建立新檔案的流程,會執行4次OSS的中繼資料查詢操作。
ossfs 2.0支援緩衝OSS返回的404請求減少後續的重複請求。開啟方式為掛載時指定:
--oss_negative_cache_timeout=30(單位:秒,預設0,建議小於attr_timeout)--oss_negative_cache_size=10000(預設10000個)
當oss negative緩衝開啟後,建立新檔案時lookup中發送的404請求會被緩衝下來,在create中重新查詢會命中negative緩衝,不再發送請求給OSS。此時原先一個建立新檔案流程中的4次OSS請求被減少成2次。
開啟oss negative緩衝後,若曾緩衝過檔案object-A的404快取項目,即便在OSS上立刻建立了object-A,也需要等到oss_negative_cache_timeout秒緩衝失效後,才能在掛載點中看到該檔案。在一致性要求高的情境不建議開啟。
效能對比
測試方法:在與目標OSS Bucket相同地區的ECS執行個體中,使用ossfs 2.0工具通過內網網域名稱掛載OSS Bucket並開啟中繼資料快取,隨後讀取已掛載Bucket目錄下10000個檔案的中繼資料。
測試結果
操作 | 耗時 |
未預載中繼資料快取(未提前執行 | 111 秒 |
預載中繼資料快取(提前執行 | 18 秒 |
測試結論:在大量檔案中繼資料讀取的情境下,提前進行預載中繼資料快取並配合合理的中繼資料快取失效時間,可以大幅減少發送至OSS的中繼資料請求次數從而提升整體效能。