持久性記憶體的揮發性優點 - Dormando（2019 年 4 月 30 日）
- memcached 如何在當今使用持久性記憶體？
- 持久性記憶體將來如何使用？
我們與 Intel 合作，使用 Intel® Optane™ DC 持久性記憶體模組（以下簡稱 PMEM）和經過最小修改的 memcached 來回答這些問題。這篇文章探討了快取系統未來程式碼架構的基準測試結果和可能性。
持久性記憶體
Intel® Optane™ DC 持久性記憶體模組是 DDR4 相容記憶體模組，可以在關閉電源後記住記憶體，而不需要電池的協助。但是，它確實需要相容的主機板和處理器才能運作。
DDR RAM 有不同的速度、功能和密度。對於伺服器而言，功能和速度往往取決於與系統中其他元件的配對：主機板、CPU 速度等。要做的主要選擇是您希望 RAM 有多密集。
伺服器的典型 DRAM 模組（截至今日）大小介於 8 到 64 GB 之間。每個密度都有自己的價格範圍
DRAM
16G $7.5/gigabyte
32G $7/gigabyte
64G $9/gigabyte
128G $35/gigabyte
128G 模組是新且稀有的，成本極高。系統建構者必須決定取捨：記憶體插槽與 DRAM 密度。雲端供應商通常需要密集、小型、便宜的系統。
英特爾的這些新模組具有 128G、256G 和 512G 的密度。每 GB 成本最低為 128G，最高為 512G。系統效能會隨著系統中模組數量的增加而擴充。
對於快取系統，128G 模組似乎符合最佳點。本文的其餘部分探討了使用 128G 模組組態的系統效能。
基準測試
在最小的變更下，或完全沒有變更時，我們會看到什麼效能特性？我們可以學到什麼關於如何設計未來的知識？我們使用三個主要配置
- 沒有程式碼變更。僅在提供的硬體上使用 DRAM 基準。
- 沒有程式碼變更，使用記憶體模式來擴充系統記憶體。
- 最小的程式碼變更：僅在持續性記憶體儲存上使用項目記憶體。
為什麼不使用 extstore？
Extstore 是 memcached 的擴充，它使用標準 SSD/NVME 裝置來卸載記憶體。它透過將元資料和金鑰資料保存在 RAM 中，並將項目的「值」部分指向儲存來達成此目的。這種權衡對於值相對較大的項目（1k-8k+）來說效果很好。在較小的尺寸（低於 1k）時，您需要相對於您可以使用的磁碟空間，使用大量的 RAM。
儘管 extstore 對於大型值來說效果很好，但 memcached 缺乏處理大量較小項目的故事。PMEM 也可以與 Extstore 結合使用：PMEM 中的項目元資料和金鑰，以及 NVME 快閃記憶體儲存中的值。
測試設定
測試使用 memcached 1.5.12 和 mc-crusher 執行 - 測試腳本 在此處提供
測試在執行 fedora 27 的單一機器上執行，其核心建置為 4.15.6。機器硬體規格為
- 2x Xeon Cascade Lake CPU（每個 24 個核心，48 個超執行緒）
- 12 x 16GB（192GB）DDR4 RAM
- 1.5TB Intel Optane DC 持續性記憶體，採用 2:2:2 配置
- 1 個用於作業系統磁碟的 SSD
測試機器是 NUMA 多插槽伺服器。一個 NUMA 節點用於執行 memcached 伺服器。另一個用於執行 mc-crusher 效能測試。還為延遲取樣程序保留了一個 CPU 核心。
進行了以下作業系統層級的組態變更
/usr/bin/echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
echo "4096" > /proc/sys/net/core/somaxconn
cpupower set -b 0
cpupower frequency-set -g performance
- Turbo 已停用以確保一致性。測試會根據專門用於 mc-crusher 的 CPU 核心數量進行調整，如果啟用 Turbo，前幾個核心會更快。它也可能導致不同的結果執行。
- 未指定最小頻率，但啟用了效能 CPU 管理程式。
- somaxconns 提高。「paced」測試使用大量快速建立的連線。這可以避免連線中斷。
- 負載產生是在 UNIX 域套接字上完成的。在跨越 NUMA 節點時，透過 localhost 的 TCP 有嚴重的效能限制和波動的結果。
延遲取樣器應用程式使用 localhost 上的 TCP，因為它本身並未遭受與主要基準測試相同的回歸。這是為了透過將 TCP 堆疊加回去，讓延遲結果更接近實際情況。
對於所有測試，項目值大小為 256 位元組。連同金鑰和元資料項目，平均略高於 300 位元組。
載入到伺服器中進行測試的金鑰數量為 1.25 億或 10 億。這提供了效能基準線，然後在超出 DRAM 的限制後顯示新增的額外負擔。在兩種情況下，雜湊表都有 93% 的載入因子，如下所述。
Memcached 的修補程式
使用了三個小修補程式來協助基準測試。
修補程式允許同時監聽 UNIX 域套接字和 TCP 套接字。這通常不被允許，因為使用者可以輕鬆地錯誤設定用戶端或意外地在網際網路上留下鎖定本機的執行個體。有了這個，我們可以在透過 UNIX 套接字產生負載的同時，透過 TCP 堆疊取樣延遲。
修補程式新增一個命令來強制雜湊表擴充。通常，在雜湊表使用率達到 1.5 倍的項目對儲存區比例後，memcached 會自動擴充其雜湊表。對於某些實驗，我們測試了過大雜湊表。詳情如下。
在使用特定用戶端標記建立項目時，修補程式會配置記憶體。這未用於基準測試，但用於實驗中。
測試
Memcached 設定
在所有情況下，memcached 都設定為使用 48 個工作執行緒。所有測試都使用相同的啟動參數，只會改變記憶體的使用量和來源。唯一的其他變更是不啟用 LRU 爬蟲。這是一個低優先順序的背景執行緒，我們確保它不會隨機干擾測試結果。
與 memcached 的連線會黏著在特定的工作執行緒上。以下所有測試至少會為每個基準測試執行緒建立足夠的連線，以利用所有 memcached 的工作執行緒。
硬體設定
此快速入門指南類似於我們為每個測試設定硬體的方式。
Optane 記憶體的不同模式在此處說明 - 我們使用記憶體模式和應用程式直接存取。
DRAM
- 這些測試僅限 DRAM，不使用持續性記憶體。這是基準效能。
記憶體模式
- 對於這些測試，已啟用記憶體模式。此模式將系統 DRAM 與持續性記憶體縫合在一起，看起來像一個大的揮發性記憶體池。資料沒有持續性。重新開機時所有資料都會遺失。
應用程式直接模式
在此模式中，DRAM 用於 memcached 的內部結構和緩衝區，以及其鏈結雜湊表的陣列。
所有項目資料：元資料、金鑰和值都直接儲存在持續性記憶體區域中。
持續性記憶體使用 DAX 檔案系統 和 memcached 的 可重新啟動模式 的原型修補程式來啟用。持續性記憶體透過 mmap 檔案存取。
注意：可重新啟動模式 已在 1.5.18 中釋出。只要新增
-e /path/to/dax/mount/memory_file，memcached 就可以使用應用程式直接模式。注意：可以 使用巨型頁面 來提升 DAX 檔案系統的效能。我們沒有測試，但它可以在某些情況下大幅提升效能。
結果
隨機選擇器
均勻 - 隨機選擇金鑰，每個金鑰都有相同的提取機會。
齊夫 - 在冪次曲線上選擇金鑰，數字較小的金鑰提取頻率較高。
金鑰數量
10 億 - 300G 以上的儲存空間。注意：DRAM 基準線永遠是 1.25 億個金鑰。
1.25 億 - 工作集適用於所有硬體組態的 RAM。
傳輸量測試：每個基準 48 個連線。核心。最大要求速率。
大量批次要求和回應。低系統呼叫速率。
大量批次要求，非批次回應。中度系統呼叫速率。
延遲測試：每個連線每 75 毫秒 50 個要求。每個基準核心 400 個連線。高系統呼叫速率。
只讀
99% 讀取，1% 寫入
90% 讀取，10% 寫入
延遲百分位數 - 僅影響延遲測試圖表
調整這些測試是一項真正的挑戰。在我們的大部分實驗中，所有三種模式運作方式幾乎相同。這裡能看出差異，是發揮創意的結果。
DRAM 是我們的基線，但由於我們沒有 400 GB 的 RAM，因此沒有簡單的方法可以將 DRAM 與大型工作負載的 PMEM 直接比較。此比較仍然有效：我們呈現的是擁有許多配備 DRAM 適用工作負載的機器與擁有遠大於 DRAM 工作負載的單一機器之間的比較。以下是幫助理解測試結果的一些快速詮釋
- DRAM 與預期相符。
- 記憶體模式處於中間。在所有測試中，接近 DRAM，每秒約 800 萬到 1000 萬個要求。
- 在「延遲」工作負載下，記憶體模式開始產生差異。當混合許多組時，它會降級到 DRAM 和 PMEM 模式之上，但不足以違反 1 毫秒的期限，直到每秒接近 800 萬個要求。
App Direct 模式是一個真正的驚喜：與記憶體模式不同，它完全不快取任何記憶體，效能卻好壞參半。
- 當工作負載符合 DRAM（1.25 億個金鑰）時，App Direct 模式的延遲非常接近，但略輸 DRAM 和記憶體模式。
- 在 10 億個項目的工作負載下，App Direct 幾乎持續擊敗記憶體模式。總體傳輸量可能較低，仍高達每秒 2000 萬個請求，但延遲相當。PMEM 在定速測試中表現得非常好，包括混合讀取/寫入場景。
Zipf 分配改善了記憶體模式和 App Direct，傳輸量和延遲大幅提升。記憶體模式更緊密地追蹤 DRAM 傳輸量。
在定速測試下，平均延遲幾乎相同。Memcached 在處理請求時很少觸及項目記憶體，因此儘管 App Direct 延遲較高，但差異會被其他所有正在進行的作業淹沒。
我們花了很多時間驗證、重新執行和重新最佳化這些測試。如果你習慣測試一般的 SSD，甚至是 NVME 驅動器，這些結果簡直不可思議。接下來讓我們討論這與生產部署的關聯性。
現在哪些有效？
Memcached 使用者有兩個瓶頸需要規劃：網路和記憶體容量。最近，extstore 使用者必須應對寫入負載過重時快閃記憶體驅動器的耗損。
網路傳輸量
傳輸量幾乎不受限制。在所有情況下，實際網路卡都會在服務之前發生故障。1000 萬個 300 位元組回應超過 20 吉位元組的流量。在幾乎所有已知的 Memcached 工作負載中，項目的大小差異很大，從幾個位元組到半兆位元組或更多。如果系統儲存了各種大小的項目，它可以輕鬆地使 50 吉位元組網路卡飽和。
讓我們採用 300b、1kb 和 2kb TCP 回應（金鑰/值 + TCP/框架標頭）。現在，假設我們測試機器的一個繁重的、有點實際的讀取負載每秒有 800 萬個請求上限，那麼 NIC 飽和是什麼樣子
在 2 千位元組的平均值下，有可能使用單一實例使 100 吉位元組 NIC 飽和。現實總是會降低這些數字：系統呼叫開銷、中斷輪詢速率等等。Memcached 目前在寫入時也沒有那麼好的擴充性。我們必須努力讓高寫入速率工作負載達到 100 吉位元組。
人們經常在專業硬體之上使用 DPDK 或類似的自訂使用者空間網路堆疊。Memcached 偏好盡可能簡化部署，並且不支援這些函式庫。此外，很少有使用者在單一節點上突破每秒 10 萬個請求，因此通常不需要這些函式庫。
從我們所見，PMEM 等同於一般網路卡的 DRAM。
記憶體密度
記憶體密度是決定公司需要多少 memcached 伺服器的另一個主要因素。您需要足夠的 RAM 才能獲得高命中率，以大幅降低後端負載，或將工作集放入記憶體中。
您能擁有的 memcached 執行個數是有極限的。在發生故障期間，其他伺服器必須承擔額外的負擔：資料庫後端負擔額外的遺漏，以及剩餘 memcached 節點的網路卡。
擁有新的密度層級也提供了更多機會來擴充資料快取的大小。快取更多來自外部資料中心、AI/ML 模型、預先計算或預先建立範本的渲染資料。
我們有強勁的開端。即使不修改現有的程式碼，此服務在任何實際情況下執行起來幾乎與 DRAM 相同。如果我們想要改善此情況，使用者必須首先對微秒的延遲極為敏感。要最佳化的另一個目標是透過減少寫入 PMEM 來延長裝置的壽命。英特爾保證 3 年的完整寫入負載，但如果公司打算在持續的重負載下使用硬體超過 5 年，這可能會很重要。儘管如此，如果由於擔心驅動器過早燒毀而無法使用快閃裝置，PMEM 是個不錯的替代方案。
就此而言，如果您符合下列任何條件，我們非常希望收到您的來信！我們不知道有任何使用者會受到此限制。
可重新啟動快取
在 1.5.18 中發布的功能允許 memcached 在正常關閉後重新啟動。對於許多工作負載而言，這是一個壞主意
但是，如果您的應用程式有能力排隊並重試快取更新或失效，或者對您的工作負載根本無關緊要，那麼可重新啟動性將會是一個巨大的好處。Memcached 池的大小為 N+1（左右）。您需要足夠的伺服器才能在其中一個伺服器發生故障時容忍額外的遺漏率。如果伺服器升級，您必須等到替換伺服器重新填滿一段時間後才能繼續進行。
在可重新啟動模式下，項目記憶體和一些元資料會儲存在共用記憶體區段中。當 memcached 重新啟動時，如果它仍然與舊資料相容，它將重建其雜湊表並提供其先前的資料。這讓升級更容易進行。無論您使用 DRAM 或 PMEM，其功能都相同。
即使如此，您在重新開機機器（例如進行核心更新）時仍然會失去快取。使用 App Direct 模式的持續性記憶體，您可以完全重新開機（甚至修復）機器而不會失去快取，因為該共用記憶體區段會在重新開機後持續存在。只要在合理的時間內完成即可！
此變更並未讓 memcached 防呆。它是在與傳統資料庫不同的權衡下設計的。
TCO
最大化網路使用率、增加記憶體密度和減少叢集大小可以將 TCO 降低多達 80%。讓我們來分解一下。
硬體成本指標
- 叢集大小：網路埠、耗電量
高階交換器 (10g、25g、50g) 每個網路埠的成本可能從數百到數千美元。減少快取伺服器數量可減少埠使用量和電費。由於 memcached 能善加利用較大的網路卡，因此分配的容量不會浪費。
- 單插槽與雙插槽伺服器
Memcached 工作負載需要較少的 CPU。使用者可能執行雙插槽系統，只是為了在單一系統中取得更多 RAM。單從雙插槽系統切換到單插槽系統，就能將每個伺服器的成本幾乎減半。
- RAM 密度
DRAM 價格總是有曲線，例如 (針對目前的伺服器 DIMM)
- 16G 模組，每 GB 7.5 美元
- 32G 模組，每 GB 7.0 美元
- 64G 模組，每 GB 9.0 美元
截至撰寫本文為止，PMEM 每 GB 的成本約為類似密度的 DRAM 的一半。
(注意：RAM 價格會波動，這些數字僅供說明之用)。
256G 32G 256G
DRAM DRAM Optane
+---+ +---+ +----+
|32G| |16G| |128G|
| | | | | |
|32G| |16G| |128G|
| | +---+ +----+
|32G|
| | $7.5/gig $4.5/gig
|32G|
| | $1392 total
|32G|
| |
|32G|
| |
|32G|
| |
|32G|
+---+
$7/gig -> $1792 total
以上面兩個範例來說：要擁有 256G 快取，一種組態可能需要 8 個 RAM 插槽，每個 GB 8 美元。RAM 的成本為 2 千美元。取得 8 個插槽也可能需要多插槽伺服器、更昂貴的主機板，或以更高的價格在較少的插槽中使用更高密度的 RAM。與 PMEM 結合仍需要一些 RAM，但總體而言，您可以將單一快取節點的成本減少數千美元。
硬體成本擴充
上述範例顯示具有 256G DRAM 的節點。效能會隨著模組新增到機器而近乎線性擴充。如果網路許可，可以使用多 TB 節點大幅減少快取叢集的大小。
大幅增加快取大小可以減少其他地方的成本：網路頻寬或跨資料中心頻寬、昂貴的資料庫伺服器、昂貴的運算節點等等。
雲端定價問題
如果您執行自己的資料中心，直接購買硬體很容易計算。PMEM 如何符合大多數人現在支付的雲端定價？
雲端定價對於這項新技術來說是一個很大的變數。最近在推出 NVME 裝置時，雲端供應商在大型執行個體中放置 4TB 以上的磁碟機，並提供最大的儲存空間和 RAM。這些執行個體非常昂貴，並不適合 memcached 或搭配 Extstore 的 memcached。
最近出現的節點具有較少的 NVME (約 750G 到 1TB)，並搭配較少的 CPU 和 RAM。我們希望雲端供應商為客戶提供符合這個市場的執行個體
- 較少的 RAM (16 到 64G)
- 較少的 CPU (4-12 個核心)
- 可擴充的 PMEM 量 (256G 到 TB)
- 可擴充的網路效能
快取和金鑰/值儲存層是大多數基礎架構的重要部分。擁有與雲端使用者需求緊密結合的執行個體，對新創公司來說可能是成敗關鍵，對既有公司來說則是一筆龐大的費用。如果使用者不必過於擔心可能難以擴充或成本高昂的架構部分，就能更快地推向市場。
結論和第二部分
Intel® Optane™ DC 持久性記憶體模組具有高密度和極低的延遲。與資料庫的需求相比，memcached 極少參照 PMEM，因此效能與 DRAM 幾乎相同：每秒數百萬個要求輕鬆勝過 1 毫秒（甚至 0.5 毫秒）SLA。PMEM 也可以透過縮小叢集規模或增加可用快取來大幅節省成本。此外，對於舊版本的 memcached，記憶體模式部署非常簡單。
有了 NVME 和現在的 PMEM，我們看到了新類型的超高密度快取叢集
- 減少資料中心之間的流量（網頁物件、影像資料、內容傳遞網路）
- 減少後端負載。
- 快取 ML 推論資料。
- 串流服務的旁路 blob 快取。
- 任何有暫時資料儲存的痛點或成本中心。
就像去年 NVME 的推出，我們認為這是資料中心儲存令人興奮的時刻。在這個產業中，革命很少發生，我們歡迎一切我們能得到的。
我們在 第二部分 繼續這個討論，探討我們在這個專案過程中思考和測試的軟體和演算法變更。