超越 RAM 的快取：NVMe 的案例 - Dormando（2018 年 6 月 12 日）

快取 RAM 細項

例如，一個 1TB 的資料庫在特定時間段內（例如 4 小時）可能只有 20% 的資料為「活動」狀態。如果您想要快取所有活動資料，您可能需要 200G 的 RAM。在這 200G 的 RAM 中，只有 20% 可能被高度使用。


在已使用的快取記憶體中，只有 10% 的 RAM 可能負責快取中所有命中率的 90%。其餘 90% 的 RAM 只占 10%。

然而，如果您削減 90% 的 RAM 使用量，您的遺失率至少會加倍，進而加倍您的資料庫負載。根據您的後端系統執行方式，損失一些 RAM 會加倍後端成本。


細分記憶體中的項目，我們可能會發現絕大多數（在上述情況中為 97.2%）只存在於 30% 的 RAM 中。少數較大但仍然重要的項目佔用了其他 70%。更大的項目甚至可以非常快速地消耗 RAM。

請記住，這些較大的項目可能是網路使用率的顯著百分比。一個 8k 要求所佔用的頻寬與 80 多個小要求相同。


extstore 如何提供協助？透過將較少最近使用的大型項目中的值與其金鑰分開並指向磁碟，我們可以節省大部分較少使用的 RAM。根據使用案例，您可以

• 減少整體 RAM：如果您有許多較大的項目，則將 100G 減少到 30G 或更少。
• 使用相同的 RAM 增加命中率：將大型項目移至磁碟，快取較小項目的較長尾端，增加命中率並降低後端成本。
• 減少伺服器數量：如果您有備用的網路（並且可以處理損壞伺服器造成的損失！），您可以減少快取機隊的規模。
• 增加整體快取：輕鬆為每個伺服器新增數百 GB 的快取容量。
• 快取過去成本過高的物件：使用較大物件建立新的池，快取來自大數據儲存、機器學習訓練資料等的預先運算資料。

其他工作負載變異是否可以？在上述範例中，快取命中均勻分佈。此理論系統的 IO 限制為 400,000，這應與高端 SSD 或 Optane 驅動器類似。在這種情況下，無法依賴 RAM 來飽和網路。

在 400,000 IOPS 下，只需 3072 位元組平均值即可飽和 10G NIC。8192 適用於 25G。在適當設計的叢集中，需要額外的空間來因應池內的成長、使用率高峰或故障。這表示項目大小可能低至 1024 位元組平均值，然而在 1024b（假設每個金鑰有 100 位元組的額外負擔）下，extstore 將只能將 RAM 中可容納的資料儲存到磁碟的 10 倍。

需要仔細的容量規劃

• 可以容忍多少台損壞的機器？每台損壞的機器都會帶走快取的一部分。
• 需要多少網路頻寬？減少伺服器數量會讓網路更密集。
• 需要多少 IOPS？大多數存取都針對近期資料，減少對磁碟的依賴。
• 需要什麼延遲保證？如果基於快取的磁碟查詢仍然比後端快很多
• 項目存活多久？SSD 在燒毀之前只能容忍一定數量的寫入。

並非所有人的工作負載都與外部儲存相容。在將磁碟用於快取之前，請仔細評估快取池中 RAM 的使用方式。如果您有獨家的小項目、簡短的 TTL 或高寫入率，RAM 仍然會更便宜。計算這個值的方法是監控 SSD 的「每日磁碟寫入」容忍度。如果一個 1TB 的裝置可以在 24 小時內以 2TB 的寫入量存活 5 年，它的容忍度為 2 DWPD。Optane 的容忍度很高，為 30DWPD，而高階快閃磁碟機為 3-6DWPD。

測試設定

這些測試是在一台 Intel Xeon 機器上進行的，配備 32 個核心、192G RAM、一個 4TB SSD 和 3 個 Optane 750G 磁碟機。測試期間只使用了一個 Optane 磁碟機。在撰寫本文時，extstore 只適用於一個磁碟機，而此組態反映了大多數使用者。

• mc-crusher 用於執行測試。特別是，第三個標籤，包含 test-optane 指令碼。
• mc-crusher 主要設計為執行得盡可能快：它不解析回應，堆疊每個系統呼叫所能處理的查詢數量，並且不嘗試計時任何內容。在此測試中，它針對 localhost 執行，儘管它從未使用超過一個 CPU 核心。
• test-optane 指令碼 特別說明了測試中使用的組態。Memcached 被組態為使用 32 個工作執行緒（這台機器有 64 個核心，含超執行緒）。
• mc-crusher 中的「balloon」程式用於佔用 125G RAM，並將 1 億個金鑰載入 memcached，以避免 extstore 僅使用緩衝池。

在每次測試執行期間，mc-crusher 客戶端數量以及伺服器中的 extstore IO 執行緒數量都會有所不同。IO 執行緒太少無法使裝置飽和，而太多執行緒會使裝置過載並可能導致佇列。

每個測試在熱身後執行一分鐘。

延遲和吞吐量測量

由於 mc-crusher 沒有計時結果，因此使用兩個指令碼來產生結果資料

• bench-sample：定期對 memcached 執行「stats」命令，使用其計數器來確定平均吞吐量。資料每隔幾秒取樣一次，並檢查是否有顯著的標準差。
• latency-sample：一個偽裝成阻擋式 memcached 客户端並在 bench-sample 執行期間「抽樣」請求的腳本。這用於避免「第 95 個百分位」等陷阱，它會移除異常值或分組，導致誤導性結果。

對於每個測試，都會提供延遲範例的完整細目。抽樣以每毫秒一次的最大速率進行。
注意：不使用事件迴圈，以避免在同時發生一組事件時，必須將經過時間判定為等待處理的時間。

測試

執行了三項一般測試

• ASCII 多重取得：此模式允許 extstore 使用最少的封包來產生回應，並在內部大量管線化請求。較低延遲的裝置可以透過此測試更輕鬆地達到較高的吞吐量。
• 管線化取得：許多取得請求堆疊在同一個封包中，但 extstore 必須獨立為每個請求提供服務。在這些測試中，extstore 能夠輕鬆飽和作業系統提供緩衝 IO 的能力（kswapd 核心執行緒達到最大值），但延遲圖表顯示 Optane 能夠將延遲保持在快閃磁碟機的十分之一。
• 在較高的客户端負載下，管線化取得可能看起來很奇怪：這需要進一步研究，但很可能是由內部排隊造成的。由於 mc-crusher 非常激進，因此 Optane 磁碟機能夠以更少的 IO 執行緒和 crusher 客户端飽和系統。在生產工作負載中，Optane 將提供更一致的低延遲服務。
• 多重取得 + 管線化設定：前兩個工作負載是唯讀的。在此測試中，設定也會針對 memcached 以大約三分之一到五分之一的速率進行。Extstore 在讀取發生的同時將資料沖洗到磁碟機。Optane 再次表現出色。

結果

不幸的是，圖表中有些許波動；這是因為在測試期間留下的 RAM 太少。Optane 的效能是一致的，而作業系統則難以跟上。

供參考：針對此 memcached 精確設定（32 個執行緒等）的純 RAM 多重取得負載測試結果為每秒 1800 萬個金鑰。更複雜的基準測試讓具有許多核心的伺服器超過每秒 5000 萬個金鑰。

使用少量的 extstore IO 執行緒 Optane 磁碟機能夠更接近飽和 IO 限制：4 個執行緒，4 個客户端：230k Optane，40k SSD。延遲細目顯示 SSD 的等待時間通常高出一個數量級，Optane 停留在 10 微秒區段，而 SSD 停留在 100 微秒區段，滑入 1 毫秒。

使用許多 extstore IO 執行緒時，底層作業系統會飽和，導致 Optane 圖表中的擺動和佇列。同時，SSD 持續受益於額外的執行緒資源，以克服快閃記憶體的額外延遲。

對於許多工作負載，SSD 和 Optane 都完全可行。如果大量讀取仍來自 RAM，而 extstore 用於服務僅限於大型物件的長尾，則它們在回應時間中都能將請求保持在 1 毫秒以下。

如果您想突破 extstore 的界限，Optane 等驅動器大有可為

• 高寫入容忍度非常適合快取工作負載
• 極低的延遲有助於緩解從磁碟請求快取資料的權衡
• 小尺寸目前具有優勢：extstore 要求磁碟上的每個值都使用 RAM。375G 至 1TB 的磁碟在特定機器中需要的 RAM 少很多，而 2TB 以上可能太密集，無法允許安全故障轉移或避免 NIC 飽和。

測試類型 批次多重取得 管線化取得 批次多重取得 + 管線化設定 SSD IO 執行緒 4 8 16 32 Optane IO 執行緒 4 8 16

學習

• extstore 沖洗器是一個背景執行緒，與管理 LRU 的程式碼結合在一起。在基準測試期間，設定會持續傳送到伺服器，這可能會導致 extstore 沖洗的飢餓。在實際應用中，插入 memcached 的速率往往會波動，即使在毫秒內也很小，因此它可以跟上。作為它自己的執行緒，這將有更一致的效能。
• 延遲取樣很困難。目前的腳本提供有用的資料，但更好的程式會將每個請求每毫秒傳送到一個封鎖執行緒池，讓我們能夠確定伺服器是否暫停或某些請求只是很慢。每個範例的完整計時也可以儲存並繪製成圖表。這將視覺化回應的群集，這些回應可能來自底層作業系統或驅動器。
• 緩衝 I/O 有限制。這在之前就知道，大多數工作負載的順序是每秒數十萬個操作或更少，而且大多數將針對 RAM 而不是 extstore。我們目前專注於穩定性，但最終直接 I/O 和非同步 I/O 將能夠在高負載下更好地利用裝置。
• Extstore 的分組可以讓 Optane 與傳統快閃記憶體混合，非常有趣。在內部，extstore 將資料組織成磁碟空間的「頁面」（通常為 64M）。新的項目會分組到特定頁面。具有短 TTL 的項目可以分組在一起。隨著時間推移，存活下來的頁面壓縮項目也會分組在一起，這減少了對壓縮的需求。所有新項目和/或短 TTL 項目都可以放在 375G Optane 驅動器上，而壓縮項目可以放在 1TB 快閃記憶體驅動器上，提供更大的成本節省。

結論

由於成本而目前無法進行的工作負載現在可以進行了。包含混合資料大小和大型池的大多數工作負載都可以顯著降低成本。

Extstore 需要每個磁碟項目使用 RAM。此圖表假設每個項目 (金鑰 + 元資料) 有 100 位元組的額外負載，可視化項目大小增加時 RAM 額外負載如何下降。

DRAM 成本是 Optane 的 3-4 倍，是 SSD 的 4-8 倍，視磁碟機而定。

當快取從 RAM 轉移到 Optane (或快閃記憶體) 時，純粹花在 RAM 上的錢可以降至三分之一。

減少 RAM 可降低對多插槽伺服器的依賴，以取得極高的 RAM 密度，通常需要具備 NUMA 功能的機器。這些機器有多個插槽、多個 CPU，一半的 RAM 連接到每個 CPU。由於 memcached 效能極高，因此您可以減少 RAM，以及在減少 RAM 後減少一半的主機板/CPU 甚至電源成本。針對特定工作負載，成本可合理降低達 80%。

高速、低延遲的 SSD 為資料庫和快取設計開啟了新紀元。我們展示了各種使用案例的高效能數字，以降低成本和擴充快取使用。