最近，ceph subreddit上的一位用戶提了一個問題：在一個由 6 個節點組成，每個節點有 2 個 4GB FireCuda NVMe 磁盤的集群中，Ceph是否可以為單個客戶端提供10K IOPs的組合隨機讀/寫能力。該用戶也想知道是否有人對類似的場景進行過測試并希望能夠共享一下測試結果。在 Clyso 項目組中，我們一直在積極努力改進 Ceph 代碼以實現更高的性能。我們有自己的測試和配置來評估我們對代碼的更改。正好，我們當前有可以匹配該用戶測試場景的硬件環境。因此，我們決定花些時間來進行測試以及驗證。

用戶環境配置

用戶的環境包含6個節點，每個節點都有2個4TB希捷FireCuda NVMe驅動器和64GB內存。關于CPU或網絡，當前沒有明確的信息。但兩者都對這次測試可能很重要。因此，我們使用如下的 fio 命令來實現這一需求：

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=150G --readwrite=randrw --rwmixread=75

雖然我們的實驗室中沒有FireCuda驅動器，但我們確實有節點具有多個4TB三星PM983驅動器和每個128GB內存。

群集配置

為了盡可能匹配用戶的環境，我們只使用了集群中的 6 個節點，其中 2 個 OSD 在單個 NVMe 驅動器上運行，每個 OSD 用于 Ceph。其余節點用作客戶端節點。所有節點都位于同一Juniper QFX5200 交換機上，并通過單個 100GbE QSFP28 連接。

下面將先部署好 Ceph，并使用 CBT 啟動 FIO 測試?；贗ntel的系統上一項重要的操作系統級別優化是將 TuneD 配置文件設置為“延遲性能”或“網絡延遲”。這主要有助于避免與 CPU C/P 狀態轉換相關的延遲峰值?；贏MD的系統在這方面并沒有太大效果，目前還沒有確認調優是否限制了C/P狀態轉換，但是對于這些測試，調優后的配置文件仍然設置為“網絡延遲”。

測試設置

用戶的環境包含6個節點，每個節點都有2個4TB希捷

CBT 需要修改幾個配置，而不使用是默認的配置來部署 Ceph。每個 OSD 分配 8GB 內存（這是合理的，因為用戶的節點有 64GB 內存用于 2 個 OSD）。RBD 卷與 Msgr V1 配合一起使用，并且 cephx 被禁用。

FIO 會先用大寫入預填充 RBD 卷，然后進行用戶的隨機讀/寫測試。某些后臺進程（如scrub, deep scrub, pg autoscaling, 以及 pg balancing）已禁用。PG 以及 PGP 設置為4096 （高于通常推薦的）和 3 副本的 RBD 池。用戶僅請求單個 FIO 卷和使用單個 150GB 文件的測試。我們按照要求對此進行了測試，但為了讓集群處于負載狀態，還運行了 16 個獨立的 FIO 進程的測試，這些進程寫入分布在 4 個客戶端節點上的專用 RBD 卷，每個卷都有一個 16GB 的文件。 為了保證與用戶的FIO設置一致，必須將 gtod_reduce 選項的支持添加到cbt的FIO基準測試工具中。 gtod_reduce 可以通過顯著減少 FIO 必須進行的 getTimeOfDay（2） 調用次數來提高性能， 但它也禁用了某些功能， 例如在測試期間收集操作延遲信息。為了評估影響，我們在啟用和禁用的情況下 gtod_reduce運行了測試：

根據結果，我們決定保持 gtod_reduce 禁用狀態，以便我們也可以觀察延遲數據。請注意，啟用此 FIO 選項可以提高大約 3-4%性能。除此之外，所有其他選項要么在CBT中可用，要么在FIO中已經默認。CBT YAML 文件的基準測試部分包含單客戶端測試的配置內容如下：

benchmarks:
  fio:
    client_endpoints: 'fiotest'
    op_size: [4096]
    iodepth: [64]
    size: 153600 # data set size per fio instance in KB
    mode: ['randrw']
    rwmixread: 75 
    procs_per_endpoint: [1]
    osd_ra: [4096]
    log_avg_msec: 100
    cmd_path: '/usr/local/bin/fio'

最終，我們實現了與用戶類似的FIO測試案例，但還有一些差異，主要與在測試過程中記錄iops/延遲數據有關：

fio --ioengine=libaio --direct=1 --bs=4096 --iodepth=64 --rw=randrw --rwmixread=75 --rwmixwrite=25 --size=153600M --numjobs=1 --name=/tmp/cbt/mnt/cbt-rbd-kernel/0/`hostname -f`-0-0 --write_iops_log=/tmp/cbt/00000000/Fio/output.0 --write_bw_log=/tmp/cbt/00000000/Fio/output.0 --write_lat_log=/tmp/cbt/00000000/Fio/output.0 --log_avg_msec=100 --output-format=json,normal > /tmp/cbt/00000000/Fio/output.0

單客戶端和多客戶端IOPS

Ceph 不僅能夠在這種混合工作負載中實現 10K IOPS，而且在單個客戶端測試中速度提高了一個數量級。針對這個小型 12 OSD 集群，我們從單個客戶端實現了大約 92K 的隨機讀取和 31K 的隨機寫入 IOPS。

另外，我們也運行多客戶端測試的原因是為了展示這個小集群在為其他客戶端提供服務時有多少空間。在相同的混合工作負載和 16 個客戶端下，我們僅用 12 個支持 NVMe 的 OSD 就實現了超過 500K 的隨機讀取和大約 170K 的隨機寫入 IOPS。在多客戶端測試中，Qunicy 和 Reef 的性能優勢分別比 Pacific 高出大約 6% 和 9%。啟用gtod_reduce可將 性能再提高 3-4%。

單客戶端和多客戶端CPU使用率

根據以往的測試，我們可以發現一個明顯的問題：CPU不足導致NVME的性能無法充分發揮。為了滿足單個客戶端工作負載，每個 OSD 大約消耗 3-4 個 AMD EPYC 內核。為了滿足多客戶端工作負載的需求，每個 OSD 消耗大量 11-12 個內核！IE 即使每個節點只有 2 個 OSD，每個節點也需要一個 24 核 EPYC 處理器才能實現這些驅動器的最大性能。更快的驅動器可能需要更大/更快的處理器。什么進程使用了所有這些 CPU？ 在以前的文章中，我們得出過如下的結論：

在某些情況下，RocksDB 壓縮線程也會定期使用 CPU 資源。BlueStore KV Sync 線程很容易成為小型隨機寫入的瓶頸，尤其是在使用較低性能的 CPU 時。但是，總體 CPU 消耗主要是在 OSD 工作線程和異步信使線程中完成的工作的結果。這是 crc 檢查、編碼/解碼、內存分配等的組合。

單客戶端和多客戶端cycles/OP

由于cycles/OP 解析代碼中的錯誤，先前的cycles/OP 計數顯著增加。這使得 OSD 的效率似乎比實際要低得多。因此，我們計算性能指標的時候，需要使用聚合平均 CPU 消耗和 IOPS 而不是聚合周期和 OPS ，校正后的數值已被驗證在預期的 ~14-17% 以內。我們認為，剩余的差異主要是由于cpu速度隨時間的變化，以及 collectl 報告的 CPU 消耗方式。

在單客戶端和多客戶端測試中，性能似乎略有提高。另外，在多客戶端測試中，我們發現在高負載下處理數據的效率要高得多，而在單客戶端測試中，我們在低負載下處理數據的效率要高得多。

為什么會這樣呢？在上一節中，我們討論了 OSD 中的大部分工作如何由 OSD 工作線程和異步信使線程完成。當 OSD 收到新 IO 時，首先由與相應網絡連接關聯的異步信使線程處理并移動到用戶空間中。然后將其放入給定 OSD 分片的計劃程序工作隊列中。如果隊列之前為空，則與該分片關聯的所有線程都會喚醒，并且在分片的工作隊列為空之前不會返回睡眠狀態。當只有 1 個客戶端執行 IO 時，集群上的負載會明顯減少，并且每個分片的隊列通常會在短時間內為空。線程會不斷喚醒并重新進入睡眠狀態。當群集負載較重時，隊列更有可能有工作要做，因此線程花費更少的睡眠和喚醒時間。相反，他們花更多的時間做實際工作。

單客戶端和多客戶端平均延遲

在單客戶端測試中，Ceph 能夠保持亞毫秒級的平均讀取和寫入延遲。在多客戶端測試中，我們看到了Pacific，Quincy和Reef之間的不同行為。Pacific的讀取延遲最低，寫入延遲最高，而Reef的讀取延遲略有增加，但寫入延遲顯著降低。Quincy的介于兩者之間，但更接近Reef而不是Pacific。

單客戶端和多客戶端99.9%延遲

正如預期的那樣，99.9% 的延遲略高。我們可以實現不到 1.3 毫秒的讀取和大約 2.1-2.3 毫秒的寫入，具體取決于版本。多客戶端測試中的尾部延遲明顯更高，但是在此測試中，Quincy 尤其是 Reef 的寫入尾部延遲明顯低于 Pacific。

結論

那么我們最后是怎么做的呢？目標是在這個混合讀/寫 FIO 工作負載中達到 10K IOPS，讀取率為 75%，寫入率為 25%。我假設這意味著目標是 7500 個讀取 IOPS 和 2500 個寫入 IOPS。讓我們比較一下我們是如何做到的：

Single-Client IOPS: 單客戶端 IOPS：

多客戶端 IOPS：

目前，我們完成了所有的測試，同時也滿足了要求！另外，如果使用更快的 NVMe 驅動器，結果應該可以進一步改善。