延遲是描述儲存裝置效能特性時最重要的指標之一，因為延遲是指儲存裝置回應資料請求所需的時間。更低的延遲等於更快的資料存取速度，並且可以顯著影響應用程式的效能，改善使用者體驗。影響延遲的因素包括各種硬體元件、網絡堆疊、工作負載特性、儲存架構和軟體堆疊。
RocksDB 是以儲存裝置為重心的關鍵值資料庫，是 Meta 許多作業的支柱。以下是摘錄自 RocksDB.org 的說明：
「RocksDB 建立在 LevelDB 上，可擴充，以在具有許多 CPU 核心的伺服器上運行，有效使用快速儲存裝置，支援受 IO 限制、記憶體內部和一次性寫入工作負載，並具彈性，為創新留有富餘量。」
Yahoo! Cloud Serving Benchmark（YCSB）專案的目標是開發一套框架性的通用工作負載，以評估不同「關鍵值」和「雲端」服務商店的效能。專案包含兩個主要組成部分：
- YCSB 用戶端：可擴充的工作負載產生器
- 核心工作負載：一組由產生器執行的工作負載情境
在執行 RocksDB YCSB 讀取繁重的工作負載時，我們多次看到大的延遲尖峰。讀取延遲預計少於 5 毫秒（與較早的執行一致），但在連續執行後，我們開始看到 113 毫秒左右的高延遲。為模擬這個問題，我們使用了 FIO 並能夠複製它。FIO 中觀察到的最大延遲為 18 毫秒，而這與 RocksDB 中觀察到的延遲不同，仍高於預期值。
對於 FIO，我們查看了一份工作檔案的事務日誌，並發現在一段相當於所看到的延遲的特定時間內沒有發生任何事件。然而，當我們查看 NVMe™ 驅動程式層時，沒有任何事務具有接近 18 毫秒的延遲，所以我們知道延遲的根源必定是應用程式。
延遲偏移不是硬碟問題，而可能是它上層的行為。
- 即使是 FIO 這樣的簡單工具，也可能遇到系統效應，導致報告高延遲。
- 系統的雜訊會影響 FIO 中報告的最大延遲
- 7x9s QoS 延遲似乎一致。
我們看到透過 BPF 追蹤指令碼測得的 RocksDB 區塊層延遲為 113 毫秒。Bpftrace 是 Linux 的追蹤框架，可讓使用者在執行階段追蹤和分析系統的各個方面。我們參考了來自 Brendan Gregg 效能工具的 BIO 窺探指令碼，該指令碼會輸出每個儲存裝置 I/O 的延遲詳細資訊，並尋找時間順序模式。
它使用 kprobes（內核探針），這是一種用於動態追蹤的 Linux 內核機制，讓使用者可在幾乎任何內核函數上插入中斷點，調用您的處理程式，然後繼續執行。
為了偵錯根本原因，我們收集了各種統計資料，以瞭解高延遲的來源。
- IO 狀態
- 裝置和分割區的系統輸入／輸出統計資料
- 在內核層測得
- 匯流排分析儀——擷取和分析在 PCIe 匯流排上傳輸的資料
- 個別事務資訊——例如事務類型、地址、資料有效負載
- 顯示訊號時序
- OCP 延遲監控
- 在硬體和韌體層測得。
總之，所觀察到的高延遲是在系統堆疊上，因為內核層、PCIe 匯流排及硬體和韌體層上的延遲與工作負載軌跡中看到的延遲尖峰都不接近。
