我欲封天耳根小说零,天域苍穹,性爱有声小说在线收听

1.背景

隨著存儲設備的升級與發展，當代的存儲設備性能越來越高，延遲也越來越低。對于內核而言，Linux I/O 存儲棧的軟件所帶來的性能開銷已經越來越不可忽視。同樣在 512B 的隨機讀條件下，在采用二代 Optane SSD 作為存儲設備的測試例?中，內核軟件（ Linux 存儲棧）所帶來的性能開銷已經?達 50%。

2.傳統方式與XRP

我們來看?個實際的例?，假設現在有?棵樹?為 4 的 B+ tree 存儲于存儲設備當中。當我們從根節點出發，?共需要經過三次訪盤才能獲得最終的葉?節點，?中間的索引節點對于?戶??沒有意義，但也需要經過?個完整的存儲棧路徑。?每次訪盤的過程中，存儲棧所花費的開銷就要整個存儲路徑的 48.6%。

顯然，冗?的存儲棧路徑鉗制了?性能存儲設備的發揮，那么?個直觀的優化思路便是通過 Kernel Bypass 的?式，繞開內核中存儲棧，以提升存儲性能。?前在學術界中，對于這??的?作有 Demikernel、Shenango、Snap 等，??業界中最為?泛使?的則是 Intel 的 SPDK。

然?，Kernel Bypass 技術并?銀彈，它雖然能夠降低內核存儲棧的開銷，但也存在著如下缺點：

1. 沒有適當粒度的訪問控制

2. 需要采? polling ?式來判斷 I/O 是否完成，這會導致在 I/O 利?率低時，Polling 進程所在的 CPU ?部分情況下只是在空轉，浪費 CPU 周期，同時 CPU 資源不能?效地在多進程中共享。

所謂 XRP 的全稱是 eXpress Resubmission Path(快速重提交路徑)。與 SPDK 完全繞開內核存儲棧，采? polling的?式來訪問存儲的?式不同，XRP 則是通過將中間請求直接在 NVMe 驅動層進? resubmission，從?避免讓中間請求通過冗?的存儲棧后再提交，從?達到加速的?的。反映到上?的例?當中，可以明顯地看到使? XRP 存儲訪問?式中，只有第?次請求和最后?次響應會經過?個完整的存儲棧路徑。顯然，在允許范圍內，B+ tree的樹?越?，XRP 的加速效果也就越明顯。

既然優化思路有了，那么應當如何才能將請求重提交于 NVMe 驅動層呢？這?可以借鑒 XDP 的實現思路。XDP 通過 eBPF 來實現對每個數據包進?獨?的操作(數據包過濾、數據包轉發、數據包追蹤、?絡調度)。XRP 也可以通過 BPF 程序來實現。

XRP 是?個使? eBPF 來降低內核存儲軟件開銷的系統。它所?臨的挑戰主要有：

1. 如何在 NVMe 驅動層實現對?件偏移的翻譯

2. 如何強化 eBPF verifier 以?持存儲應?場景

3. 如何重新提交 NVMe 請求

4. 如何與應?層 Cache 進?交互

XRP 引?了?種新的 BPF 類型(BPF_PROG_TYPE_XRP)，包含了 5 個字段，分別是

1. char* data：?個緩沖區，?于緩沖從磁盤中讀取出來的數據

2. int done：布爾語意，表示 resubmission 邏輯是否應當返回給 user，還是應當繼續 resubmitting I/O 請求

3. uint64_t next_addr[16]：邏輯地址數組，存放的是下次 resubmission 的邏輯地址

4. uint64_t size[16]：存放的是下次 resubmission 的請求的??5. char* scratch：user 和 BPF 函數的私有空間，?來傳遞從 user 到 BPF 函數的參數。BPF 函數也可以?這段

空間來保存中間數據。處于簡單考慮，默認 scratch 的??是 4KB。

同時，為了避免因存在?限循環?導致 BPF Verifier 驗證失敗，代碼中指定了 B+ tree 的最?扇出數為

MAX_FANOUT，其值為 16。

?前，最常?鏈式讀請求主要有 B-Tree 和 LSM Tree 兩種，? XRP 分別繼承了 BPF-KV（?個簡易的基于 B+ Tree的鍵值存儲引擎）和 WIREDTIGER（mongoDB 的后端鍵值存儲引擎）。

3.實驗測試

上圖為在 512B 隨機讀測試中，標準 read 和 XRP 之間的性能對?測試。可以看到隨著線程數的增加，XRP 的吞吐保持線性增?的態勢，同時 XRP 通過降低每次 I/O 請求時的 CPU 開銷，從?緩解了 CPU 爭?問題。

上?兩幅圖中，同樣表示了在 512B 隨機讀測試中（CPU 核?數為 6），標準 read、XRP 和 SPDK 之間的吞吐量以及尾延遲的對?。在線程數?于等于 CPU 核?數時，三者性能變化穩定，從?到低依次為 SPDK > XRP >read。?當線程數超過了核?數時，SPDK 性能開始出現嚴重的下跌，標準 read 性能輕微下滑，? XRP 依然保持著穩定的線性增?。這主要是因為 SPDK 采? polling 的?式訪問存儲設備的完成隊列，當線程數超過核?數，線程之間對 CPU 的爭奪加上缺乏同步性，會導致所有線程都經歷尾部延遲顯著提升和整體吞吐量的顯著下降。

4.總結