客觀的
此測試的目的是展示使用 INTEL SSDPEYKX040T8 NVMe 驅動器在 Ceph 集群（特別是 CephFS）中可實現的最大性能。為避免指控供應商作弊，使用行業標准 IO500 基准測試來評估整個存儲設置的性能。
劇透：盡管只使用了 5 節點的 Ceph 集群，因此無法正式提交結果（至少需要 10 個節點），但獲得的基准分數已經足以進入最佳列表的前 40 名-執行 2019 年的 10 節點存儲系統。
硬件
向 croit 提供了一個由連接到 100Gbps 網絡的七台 Supermicro 服務器組成的實驗室。其中六台服務器具有以下規格：
- 型號：SSG-1029P-NES32R
- 基板：X11DSF-E
- CPU：2x Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz（Turbo 頻率高達 3.70 GHz），總共 96 個虛擬內核
- RAM：8x Micron Technology 36ASF4G72PZ-2G9E2 32GB DDR4 DIMM，即總共 256 GB，配置為 2400 MT/s 但能夠達到 2933 MT/s
- 存儲：8 個 INTEL SSDPEYKX040T8 NVMe 驅動器，每個 4TB
- 輔助存儲：64GB SATA SSD
- 板載網絡：2 個英特爾公司以太網控制器 10G X550T [8086:1563]
- PCIe 以太網卡：Mellanox Technologies MT27700 系列 [ConnectX-4] [15b3:1013]，具有兩個 QSFP 端口，每個端口能夠達到 100 Gbps
此外，還有一台具有不同配置的服務器：
- 型號：SSG-1029P-NMR36L
- 基板：X11DSF-E
- CPU：Intel(R) Xeon(R) Gold 6138 CPU @ 2.00GHz（Turbo 頻率高達 3.70 GHz），總共 80 個虛擬內核
- RAM：8x SK Hynix HMA84GR7CJR4N-WM 32GB DDR4 DIMM，即總共 256 GB，配置為 2666 MT/s，但能夠達到 2933 MT/s
- 存儲：32 個 SAMSUNG MZ4LB3T8HALS NVMe 驅動器，每個 3.84 TB（未使用）
- 輔助存儲：64GB SATA SSD
- 板載網絡：2 個英特爾公司以太網控制器 10G X550T [8086:1563]
- PCIe 以太網卡：Mellanox Technologies MT27700 系列 [ConnectX-4] [15b3:1013]，具有兩個 QSFP 端口，每個端口能夠達到 100 Gbps
在所有服務器上，板載網絡僅用於 IPMI 和管理目的。在每個 Mellanox 網卡的兩個 100Gbe 端口中，只有一個使用直連銅纜連接到運行 Cumulus Linux 4.2 的 SSE-C3632S 交換機。
軟件
在測試期間，SSG-1029P-NMR36L 服務器被用作 croit 管理服務器，並作為運行基准測試的主機。由於（正確地）懷疑單個 100Gbps 鏈路不足以揭示集群的性能，因此其中一台 SSG-1029P-NES32R 服務器也專用於客戶端角色。在這兩台服務器上，都安裝了 Debian 10.5。內核是從 Debian “backports” 存儲庫安裝的，以便獲得 cephfs 客戶端的最新改進。
其余五台 SSG-1029P-NES32R 服務器用於 Ceph 集群（使用 Ceph 14.2.9），方法是從管理節點對它們進行網絡引導。內核版本是 4.19。
CEPH 集群
五台服務器參與了 Ceph 集群。在三台服務器上，小型 SATA SSD 用於 MON 磁盤。在每個 NVMe 驅動器上，都創建了一個 OSD。在每台服務器上，都配置了一個 MDS（負責 cephfs 元數據操作的 Ceph 組件）。為了盡可能並行化元數據操作（即在基准測試的“簡單”部分），四個 MDS 服務器被標記為活動的，其余的一個作為備用服務器。應該注意的是，具有多個活動 MDS 服務器的配置是否適用於生產 Ceph 集群仍然存在爭議。
在客戶端節點上，使用了內核 cephfs 客戶端，通過 /etc/fstab 中的這一行：
:/ /mnt/cephfs ceph name=admin,_netdev 0 0
所有客戶端和服務器都在一個 L2 網段，網絡為 10.10.49.0/24。設置了無密碼 ssh，因為這是 OpenMPI 的要求，IO500 基准測試使用 OpenMPI 以並行和分布式方式運行工作程序。
最初，打算將基准測試結果與每個節點有 6 個 OSD 的另一個 Ceph 集群進行比較。因此，每個主機上的兩個 NVMe 驅動器通過為它們分配一個單獨的設備類而被擱置一旁。然而，這一意圖從未實現。盡管如此，大多數基准測試都是在每個節點僅使用 6 個 NVMe OSD 完成的。
可用存儲分為三個池：cephfs_metadata（64 個 PG）、cephfs_data（512 個 PG）和 rbd_benchmark（也是 512 個 PG）。因此，雖然每個 OSD 的 PG 總數接近理想值，但 cephfs 使用的數據池中的 PG 數量少於本例中通常使用的 PG 數量（即 1024）。這里的理論是太少的 PG 會導致數據不平衡（我們並不真正關心），而太多的 PG 可能會產生性能問題。
IO500 基准
IO500 是由 Virtual Institute for I/O 管理的存儲基准。它測量不同場景下基於集群的文件系統的帶寬和 IOPS 數據，並將最終分數作為在所有測試階段獲得的性能指標的幾何平均值得出。在每個階段，執行“ior”工具（用於帶寬測試）或“mdtest”工具（用於測試各種元數據操作的性能）的多個副本，並將結果合並。還有一個基於並行“查找”類程序的階段。作為實現細節，MPI 用於編排。
執行階段的順序以這樣一種方式組織，即基於 ior 和基於 mdtest 的階段大多相互交錯。
帶寬測試階段
帶寬測試是使用“ior”工具完成的。有兩個“難度”級別（簡單和困難），對於每個級別，帶寬都是針對寫入和單獨的讀取來測量的。基准測試結束時報告的帶寬數字是所有四個測試的幾何平均值。
默認情況下，兩個難度級別的寫入時間為 5 分鍾，使用 POSIX 原語進行文件系統訪問。在簡單模式下，每個 ior 進程使用一個文件，寫入按順序完成，傳輸大小為 256 KiB。在硬模式下，所有進程寫入同一文件的交錯部分，使用奇怪的 47008 字節傳輸大小和“跳躍”線性訪問（lseek() 對其他進程要寫入的字節，寫入 47008 字節，重復循環）。在這兩種情況下，每個進程最后只執行一次 fsync() 調用，即，基本上以無限的隊列深度工作。
對於有多個客戶端的 CephFS，“硬”I/O 模式確實很難：每次寫入都會導致 RADOS 對象的部分修改以前被另一個客戶端接觸過，並且可能被另一個客戶端同時接觸，因此寫入有以原子方式執行。沒有 fsync() 調用除了最后也無濟於事：fsync() 保證數據命中穩定存儲，但是這個測試關心的是客戶端之間的數據一致性，這是完全不同的事情，不能轉在符合 POSIX 的文件系統中關閉。因此，即使測試以 GiB/s 顯示結果，它主要受客戶端和元數據服務器之間的通信延遲的影響。
對於閱讀，簡單測試和困難測試都使用與之前編寫的相同的文件，以相同的方式訪問它們，並驗證文件中的數據是否與預期的簽名匹配。
IOPS 測試階段
幾乎所有的 IOPS 測試都是使用“mdtest”工具完成的。與 ior 不同的是，mdtest 會創建大量文件並強調元數據操作。
就像帶寬測試一樣，測試運行有兩個“難度”級別：簡單和困難。對於每個難度，每個進程在“創建”階段創建大量測試文件（最多一百萬），然后在測試的“統計”階段檢查所有文件，然后在“刪除”階段刪除. 在每個階段結束時，都會執行“同步”命令，並考慮其運行時間。
難考與易考的區別在於以下幾個方面：
-
簡單測試中每個文件為空，在“創建”階段寫入 3901 字節，稍后在硬測試中讀回；
-
在簡單的情況下，每個進程都有一個唯一的工作目錄，而在困難的情況下使用一個共享目錄。
原始存儲性能
Croit 帶有一個內置的基於 fio 的基准，用於評估數據庫應用程序中磁盤驅動器的原始性能。基准測試在后台運行此命令以獲取並行作業數量的各種值（從 1 到 16）：
fio --filename=/dev/XXX --direct=1 --fsync=1 --rw=write --bs=4k --numjobs=YYY --iodepth=1 --runtime=60 --time_based --group_reporting --name=4k-sync-write-YYY沒有理由不將此基准用作表征 NVMe 驅動器的“至少某種東西”，並用於客觀地比較它們在各種 BIOS 設置下的性能。
直接的發現之一是不同的服務器具有不同的性能，尤其是在基准測試的 1-job 變體中，IOPS 介於 78K 和 91K 之間。16 個作業的數據更加一致，僅顯示 548K（奇怪的是，在 1 個作業基准測試中最快的服務器上）和 566K IOPS 之間的差異。
最初認為這種變化的原因在於最初出現在“CPU 配置”菜單中的服務器上的不同 BIOS 設置。事實上，從高性能存儲讀取數據本身就是一項 CPU 密集型活動：在這種情況下，fio 消耗了 30% 的 CPU，而“ kworker/4:1H-kblockd”內核線程則消耗了 12%。因此，讓 CPU 達到盡可能高的時鍾頻率是合理的。
與直覺相反，將 BIOS 的“高級電源管理配置”區域中的“電源技術”參數設置為“禁用”是錯誤的做法。它將 CPU 頻率鎖定在最高的非渦輪狀態，即 2.10 GHz，並使 3.70 GHz 頻率不可用。然后，fio 存儲基准測試只能產生 66K IOPS，這太糟糕了。
此 BIOS 區域中的另一個選項決定是 BIOS 還是操作系統控制能效偏差。如果控制權交給 BIOS，有一個設置告訴它做什么，而對於“Power Technology”參數的“Manual”設置，有很多選項可以微調 C-、P- 和T 狀態。考慮到能源性能偏差控制以及對 C-、P-、 CPU 的 T 狀態和 T 狀態被提供給操作系統。在這兩種情況下，NVMes 最初的基准測試都是 89K-91K IOPS。不幸的是，后來的一些調整（不知道究竟是什么）破壞了這一成就，最終結果再次導致單線程 84K 和 87K 寫入 IOPS 之間的性能不一致。
好吧，至少，從那時起，所有服務器上的 BIOS 設置都變得一致了——見下表。這些設置背后的想法是盡可能多地控制 CPU 狀態給操作系統，而不是硬件或 BIOS。croit 還發現超線程、LLC Prefetch 和 Extended APIC 並沒有顯着影響存儲性能。因此，啟用了所有 CPU 功能。
| BIOS 設置 | 價值 |
| 超線程 [全部] | 使能夠 |
| 啟用核心 | 0（全部） |
| 監視器/Mwait | 汽車 |
| 執行禁用位 | 使能夠 |
| 英特爾虛擬化技術 | 使能夠 |
| PPIN 控制 | 解鎖/啟用 |
| 硬件預取器 | 使能夠 |
| 相鄰緩存預取 | 使能夠 |
| DCU 流媒體預取器 | 使能夠 |
| DCU IP 預取器 | 使能夠 |
| LLC預取 | 使能夠 |
| 擴展 APIC | 使能夠 |
| AES-NI | 使能夠 |
| 電源技術 | 風俗 |
| 電源性能調整 | 操作系統控制 EPB |
| SpeedStep（P 狀態） | 使能夠 |
| EIST PSD 函數 | HW_ALL |
| 渦輪模式 | 使能夠 |
| 硬件 P 狀態 | 禁用 |
| 自治核心 C 狀態 | 禁用 |
| CPU C6 報告 | 汽車 |
| 增強的停止狀態 (C1E) | 使能夠 |
| 包 C 狀態 | 汽車 |
| 軟件控制的 T 狀態 | 使能夠 |
網絡性能
Mellanox 適配器無需任何調整即可達到 85+ Gbps 的吞吐量，但為此需要多個 TCP 流。將 net.core.rmem_max sysctl 設置為一個巨大的值將進一步將可實現的吞吐量提高到 94 Gbit/s，但不會提高基准分數，因此沒有完成。
為了展示出色的吞吐量，我們在兩台主機上運行了 iperf（版本 2.0.12），如下所示：
在“服務器”上： iperf -s -p 9999
在“客戶端”上： iperf -c 10.10.49.33 -p 9999，其中 10.10.49.33 是服務器 IP
對於單個 TCP 流（如上所示），iperf 指示 39.5 Gbit/s 的吞吐量。為了同時使用四個流，在客戶端添加了“-P 4”參數，這使吞吐量達到了 87.8 Gbit/s。
吞吐量很好，但請記住，有些 IOR500 測試實際上是針對延遲的，它也需要優化。對於延遲測試，我們使用了兩個客觀基准：
-
在 RBD 設備上測量 4k 大小的寫入 IOPS；
-
只是ping另一個主機。
RBD 基准測試命令（比 IOR500 更激進）是：
fio --ioengine=rbd --pool=rbd_benchmark --rbdname=rbd0 --direct=1 --fsync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=4k-sync-write-1
未經任何調整，它僅達到 441 IOPS。是的，與原始存儲相比，減少了 200 多倍。
這里的限制因素之一是 CPU 時鍾速度。Linux 內核中默認的“powersave”CPU 頻率調節器將 CPU 時鍾保持在較低水平，直到它發現工作負載過於繁重。在這種情況下，它可能仍然“太容易”（27%），並且不被視為提高頻率的充分理由——這可以通過grep MHz /proc/cpuinfo | sort | tail -n 4與 fio 同時運行類似 '' 來確認。
一旦客戶端和 Ceph OSD 節點 ( cpupower frequency-set -g performance) 上的 CPU 頻率調節器都更改為“性能”，情況就會改善：2369 IOPS。
優化網絡延遲
正如已經提到的，IO500 基准測試對網絡延遲很敏感。如果不進行任何調整，延遲（由“ping”命令報告）為 0.178 毫秒，這意味着在整個請求-響應周期中，僅浪費了 0.356 毫秒。這里的 ping 時間加倍，因為有兩跳對延遲很重要：從客戶端到主 OSD，以及從主 OSD 到輔助 OSD。上一節的 fio 基准測試中每秒有 2369 個這樣的周期，因此每個周期平均持續 0.422 毫秒。因此，減少延遲似乎非常重要。
事實證明，CPU 負載足夠低，並且它的內核通過進入節能 C 狀態來“打盹”。最深的這種狀態是C6，根據“ cpupower idle-info”，它需要0.133毫秒才能從它過渡出來。接下來的狀態是 C1E、C1 和“CPUIDLE CORE POLL IDLE”（不節省任何電量），所有這些狀態都需要不到 0.01 毫秒的時間才能退出。因此，下一個調整步驟是禁用 C6 狀態。執行此操作的命令“ cpupower idle-set -D 11”實際上意味着“禁用所有需要超過 0.011 毫秒才能退出的空閑狀態”。結果：ping 時間下降到 0.054 毫秒，但 fio 基准測試僅產生 2079 IOPS - 比以前更差。這可能是因為不在 C6 中的內核降低了 CPU 可用的最大頻率，並且，在這個“fio”基准測試中，達到可能的最高頻率實際上更為重要。
盡管如此，正如我們稍后將看到的，禁用 C6 對整體 IO500 得分是有益的。
實際運行 IO500 基准測試
IO500 基准測試的源代碼來自 https://github.com/VI4IO/io500-app。來自“io500-isc20”分支的代碼（當時指向提交 46e0e53）無法編譯，因為“extern”變量使用不當。幸運的是，該錯誤修復可從同一存儲庫的主分支獲得。因此，所有基准測試都是通過提交 20efd24 完成的。我們知道新的 IO500 版本已於 2020 年 10 月 7 日創建，但為了保持一致性，繼續提交 46e0e53。
基准測試的主腳本名為“ io500.sh”。在文件的頂部，有一個“ io500_mpiargs”變量，默認設置為“ -np 2”，意思是“在本地運行兩個進程”。為了測試分布式操作是否有效，將此變量更改為“ -np 4 -mca btl ^openib -mca btl_tcp_if_include 10.10.49.0/24 -oversubscribe -H 10.10.49.2,10.10.49.33 --allow-run-as-root”，以便在兩個客戶端節點的每一個上啟動兩個進程。
“ -mca btl ^openib”參數將 InfiniBand 從 OpenMPI 嘗試的傳輸列表中排除。這是必要的，因為 Mellanox 網絡適配器理論上支持 InfiniBand，但該集群中尚未配置 InfiniBand。基准測試不需要在工作人員之間發送大量數據，因此回退到 TCP 是可以接受的。
“ -mca btl_tcp_if_include 10.10.49.0/24”參數指定在 OpenMPI 基准測試期間要使用的網絡。如果沒有這個參數，OpenMPI 有時會選擇其中一台主機上的 docker0 接口作為主接口，並嘗試從其他節點連接到 172.17.0.1，這將失敗。
基准測試的所有階段運行兩次，一次使用 shell 腳本進行協調，一次使用 C 程序。這兩個“驅動程序”以略微不同的格式打印結果，但在數量上並沒有太大差異。出於這個原因，下面只提到基於 shell 的驅動程序報告的基准分數。
基准測試還需要一個配置文件。一個廣泛評論的示例 config-full.ini 與基准源一起提供。但是，只需要幾個選項：IO500 將寫入數據的目錄、刪除緩存的可選腳本以及用於調試的縮短基准測試持續時間的方法。在找到最佳選項之前，每次都執行完整的基准測試是沒有意義的，因此，石牆計時器設置為 30 秒。
[global]datadir = /mnt/cephfs/defaultdrop-caches = TRUEdrop-caches-cmd = /usr/local/bin/drop_caches
[debug]stonewall-time = 30
/usr/local/bin/drop_caches 腳本的內容 是：
#!/bin/shecho 3 > /proc/sys/vm/drop_cachesssh 10.10.49.33 echo 3 ">" /proc/sys/vm/drop_caches
是否禁用 C6
30 秒版本的基准測試運行良好，並在完全未調整（操作系統調整除外）集群上生成此報告，啟用 C6 空閑狀態（這是默認設置）：
[RESULT] BW phase 1 ior_easy_write 6.021 GiB/s : time 35.83 seconds
[RESULT] BW phase 2 ior_hard_write 0.068 GiB/s : time 43.69 seconds
[RESULT] BW phase 3 ior_easy_read 5.144 GiB/s : time 46.86 seconds
[RESULT] BW phase 4 ior_hard_read 0.219 GiB/s : time 13.52 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 10.334 kiops : time 32.09 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 5.509 kiops : time 45.68 seconds
[RESULT] IOPS phase 3 find 123.770 kiops : time 4.71 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 31.086 kiops : time 10.67 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 30.733 kiops : time 8.19 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 4.868 kiops : time 68.13 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 5.734 kiops : time 43.88 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 3.443 kiops : time 75.07 seconds
[SCORE] Bandwidth 0.822726 GiB/s : IOPS 12.6286 kiops : TOTAL 3.22333禁用 C6 后，“ior_hard_write”測試得到顯着提升，但大多數其他測試的結果更差。盡管如此，由於帶寬和 IOPS，總體得分還是略有提高：
[RESULT] BW phase 1 ior_easy_write 5.608 GiB/s : time 35.97 seconds
[RESULT] BW phase 2 ior_hard_write 0.101 GiB/s : time 36.17 seconds
[RESULT] BW phase 3 ior_easy_read 4.384 GiB/s : time 47.43 seconds
[RESULT] BW phase 4 ior_hard_read 0.223 GiB/s : time 16.30 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 10.614 kiops : time 31.73 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 4.884 kiops : time 43.06 seconds
[RESULT] IOPS phase 3 find 157.530 kiops : time 3.47 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 26.136 kiops : time 12.88 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 30.081 kiops : time 6.99 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 5.122 kiops : time 65.74 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 7.689 kiops : time 27.35 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 3.382 kiops : time 64.18 seconds
[SCORE] Bandwidth 0.86169 GiB/s : IOPS 13.0773 kiops : TOTAL 3.35687這並不奇怪：ior_easy_write 步驟在“ior”進程消耗 100% CPU 時出現瓶頸，並且 C6 中零內核的可用時鍾速度低於其他情況。為了避免這種 CPU 核心飽和現象，我們進行了單獨的測試，每個主機有 4 個進程（而不是 2 個）。
啟用 C6 的結果：
[RESULT] BW phase 1 ior_easy_write 7.058 GiB/s : time 38.88 seconds
[RESULT] BW phase 2 ior_hard_write 0.074 GiB/s : time 39.40 seconds
[RESULT] BW phase 3 ior_easy_read 7.933 GiB/s : time 34.78 seconds
[RESULT] BW phase 4 ior_hard_read 0.172 GiB/s : time 16.97 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 11.416 kiops : time 34.38 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 5.492 kiops : time 43.10 seconds
[RESULT] IOPS phase 3 find 169.540 kiops : time 3.71 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 41.339 kiops : time 9.50 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 47.345 kiops : time 5.00 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 8.997 kiops : time 43.63 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 9.854 kiops : time 24.02 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 3.213 kiops : time 75.66 seconds
[SCORE] Bandwidth 0.919144 GiB/s : IOPS 16.6569 kiops : TOTAL 3.91281禁用 C6 的結果：
[RESULT] BW phase 1 ior_easy_write 5.983 GiB/s : time 39.96 seconds
[RESULT] BW phase 2 ior_hard_write 0.100 GiB/s : time 37.91 seconds
[RESULT] BW phase 3 ior_easy_read 7.413 GiB/s : time 31.65 seconds
[RESULT] BW phase 4 ior_hard_read 0.232 GiB/s : time 16.26 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 9.793 kiops : time 35.57 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 4.845 kiops : time 36.70 seconds
[RESULT] IOPS phase 3 find 147.360 kiops : time 3.57 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 50.768 kiops : time 6.86 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 50.125 kiops : time 3.55 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 7.763 kiops : time 44.87 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 13.135 kiops : time 13.54 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 3.699 kiops : time 50.04 seconds
[SCORE] Bandwidth 1.00608 GiB/s : IOPS 16.918 kiops : TOTAL 4.12563結論保持不變：禁用 C6 的建議並不普遍。它有助於基准測試的一些“困難”地方，但會傷害其他地方。盡管如此，它在兩種情況下都略微提高了整體分數，因此在其余基准測試中禁用了 C6。
調整 MDS
簡短版的測試運行順利。但是，在使用默認 300 秒石牆計時器的完整基准測試期間（特別是在“mdtest_hard_write”階段），觀察到一些 MDS 健康警告：
-
MDSs 落后於修剪
-
MDS 報告緩存過大
-
客戶端無法響應緩存壓力
最終得分也較低，特別是由於基於 mdtest 的“stat”測試：
[RESULT] BW phase 1 ior_easy_write 5.442 GiB/s : time 314.02 seconds
[RESULT] BW phase 2 ior_hard_write 0.099 GiB/s : time 363.64 seconds
[RESULT] BW phase 3 ior_easy_read 7.838 GiB/s : time 215.95 seconds
[RESULT] BW phase 4 ior_hard_read 0.231 GiB/s : time 155.15 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 11.423 kiops : time 431.68 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 5.518 kiops : time 328.02 seconds
[RESULT] IOPS phase 3 find 120.880 kiops : time 55.76 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 0.866 kiops : time 5694.08 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 2.072 kiops : time 873.55 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 1.972 kiops : time 2500.54 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 1.925 kiops : time 940.46 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 3.304 kiops : time 549.71 seconds
[SCORE] Bandwidth 0.99279 GiB/s : IOPS 4.51093 kiops : TOTAL 2.11622顯然，MDS 被基准測試創建的元數據負載壓得喘不過氣來。因此，決定將“mds 緩存內存限制” Ceph 參數從默認值 1 GB 增加到 12884901888 (12 GB)。選擇的確切值是健康警告中報告的峰值緩存大小的 2 倍。這幾乎恢復了在基准測試的簡短版本中看到的分數：
[RESULT] BW phase 1 ior_easy_write 5.274 GiB/s : time 322.44 seconds
[RESULT] BW phase 2 ior_hard_write 0.105 GiB/s : time 348.94 seconds
[RESULT] BW phase 3 ior_easy_read 7.738 GiB/s : time 217.92 seconds
[RESULT] BW phase 4 ior_hard_read 0.239 GiB/s : time 153.87 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 10.692 kiops : time 429.36 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 5.318 kiops : time 324.34 seconds
[RESULT] IOPS phase 3 find 211.550 kiops : time 29.85 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 44.120 kiops : time 104.05 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 29.881 kiops : time 57.72 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 6.993 kiops : time 656.42 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 9.773 kiops : time 176.46 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 2.949 kiops : time 586.78 seconds
[SCORE] Bandwidth 1.0071 GiB/s : IOPS 15.4197 kiops : TOTAL 3.94071消除客戶端瓶頸
將每台主機的 worker 數量增加到 4 個以上並沒有提高 IO500 分數，也沒有增加 OSD 的 CPU 使用率。在這種情況下，“ior”階段可能的瓶頸是單個客戶端“kworker/u194:0+flush-ceph-1”線程，它消耗了 70-80% 的 CPU。這個線程是單線程的，因為一台主機上的所有工作進程只使用一個 cephfs 掛載。
很明顯，解決方案是多次掛載 cephfs，這樣它們就不會共享一個“kworker/u194:0+flush-ceph-1”線程。此掛載選項稱為“noshare”。以下是“mount.ceph”手冊頁中的描述：
創建一個新的客戶端實例，而不是共享掛載同一集群的現有客戶端實例。
但是，IO500 基准測試並非旨在通過多個掛載點訪問存儲。為了規避這個限制，在每個客戶端主機上創建了多個 LXC 容器，每個容器都有一個單獨的 cephfs 掛載。對於網絡，使用了“macvlan”后端，以便將每個容器直接暴露給 100Gbps 網絡，而不會因路由而產生額外開銷。在每個主機本身上，都添加了一個單獨的 macvlan 接口，以便容器可以與主機通信。以下是相關部分 /etc/network/interfaces：
iface enp216s0f0np0 inet manual
up /sbin/ip link add link enp216s0f0np0 name enp216s0f0mv0 type macvlan mode bridge
allow-hotplug enp216s0f0mv0
iface enp216s0f0mv0 inet static
address 10.10.49.2/24無法從容器中刷新 Linux 緩存，因此，容器中的“ /usr/local/bin/drop_caches”腳本必須修改如下：
#!/bin/sh
ssh 10.10.49.2 echo 3 ">" /proc/sys/vm/drop_caches
ssh 10.10.49.33 echo 3 ">" /proc/sys/vm/drop_caches也就是說，它將通過 ssh 連接到兩個客戶端主機，並以通常的方式刷新緩存。
每個主機四個容器，每個容器三個或四個工作進程獲得了最佳結果。規定這一點的 mpirun 參數是：“ -np 32 -oversubscribe -H 10.10.49.3,10.10.49.4,... --allow-run-as-root”。事實上，使用 30 秒的石牆計時器，基准測試的某些階段，例如“mdtest_hard_stat”，變得太短（不到 4 秒），結果變得可靠和可重復。因此，從此時起，基准測試使用 300 秒的石牆計時器運行。
以下是每個容器三個進程的基准測試結果：
[RESULT] BW phase 1 ior_easy_write 11.307 GiB/s : time 372.62 seconds
[RESULT] BW phase 2 ior_hard_write 0.383 GiB/s : time 352.78 seconds
[RESULT] BW phase 3 ior_easy_read 15.144 GiB/s : time 277.94 seconds
[RESULT] BW phase 4 ior_hard_read 0.931 GiB/s : time 145.10 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 14.032 kiops : time 472.96 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 9.891 kiops : time 313.09 seconds
[RESULT] IOPS phase 3 find 231.190 kiops : time 42.10 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 55.821 kiops : time 118.89 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 79.348 kiops : time 39.03 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 9.597 kiops : time 691.54 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 16.702 kiops : time 185.42 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 8.507 kiops : time 366.75 seconds
[SCORE] Bandwidth 2.79532 GiB/s : IOPS 25.7583 kiops : TOTAL 8.48544每個容器有四個進程，一些基准測試結果（特別是“mdtest_hard_read”）看起來更好，但其他看起來更糟，集群肯定感覺過載（報告的中值延遲接近 0.5 秒）。因此，這里每個容器使用三個或四個工作進程是否更好是有爭議的。以下是基准測試結果：
[RESULT] BW phase 1 ior_easy_write 11.459 GiB/s : time 350.88 seconds
[RESULT] BW phase 2 ior_hard_write 0.373 GiB/s : time 354.69 seconds
[RESULT] BW phase 3 ior_easy_read 16.011 GiB/s : time 250.28 seconds
[RESULT] BW phase 4 ior_hard_read 0.930 GiB/s : time 142.02 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 15.894 kiops : time 441.59 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 10.690 kiops : time 313.34 seconds
[RESULT] IOPS phase 3 find 174.440 kiops : time 59.44 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 55.944 kiops : time 125.46 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 66.896 kiops : time 50.07 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 9.371 kiops : time 748.99 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 19.120 kiops : time 175.18 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 9.948 kiops : time 340.54 seconds
[SCORE] Bandwidth 2.82402 GiB/s : IOPS 25.8226 kiops : TOTAL 8.53953這是一個相當嚴重的負載：在 Ceph 集群中，每個 OSD cpu 消耗在“ior_easy_write”階段達到約 400% 的峰值。這也是第一次觀察到總客戶端吞吐量超過單個 100Gbps 鏈路的能力。
擴展 MDSS
前面幾節中執行的 MDS 調優顯然已經完成了——在“mdtest_easy_delete”和“mdtest_hard_delete”兩個階段，每個活動 ceph-mds 進程的 CPU 使用率都接近 100%。換句話說，只有四個活動的 MDS，這與集群在這些元數據密集型基准測試中的運行速度差不多。
但是誰說有五台物理服務器，一台受限於四台活動 MDS 和一台備用？croit 用戶界面。Ceph 官方文檔 提到每個節點多個 MDS 作為 MDS 瓶頸的可能解決方案：
即使單個 MDS 守護程序無法充分利用硬件，稍后可能需要在同一節點上啟動更多活動的 MDS 守護程序以充分利用可用的內核和內存。此外，集群上的工作負載可能會清楚地表明，在同一節點上使用多個活動 MDS 會提高性能，而不是過度配置單個 MDS。
事實上，我們發現即使每個主機有兩個 MDS 也不足以避免瓶頸。因此，我們總共部署了 20 個 MDS——每台主機 4 個，並使其中 16 個處於活動狀態。因此，這是我們使用的手動程序。
在每台主機上，必須（暫時）將管理員密鑰環保存為 /etc/ceph/ceph.client.admin.keyring. 之后，執行以下命令，替換正確的主機名，而不是 croit-host-25 為新的 MDS 組成唯一的名稱。
# sudo -u ceph -s /bin/bash
$ mkdir /var/lib/ceph/mds/ceph-croit-host-25a
$ ceph-authtool --create-keyring /var/lib/ceph/mds/ceph-croit-host-25a/keyring --gen-key -n mds.croit-host-25a
$ ceph auth add mds.croit-host-25a osd "allow rwx" mds "allow" mon "allow profile mds" -i /var/lib/ceph/mds/ceph-croit-host-25a/keyring
$ cat /var/lib/ceph/mds/ceph-croit-host-25a/keyring結果，每個主機擁有三個新的有效密鑰環，每個未來的 MDS 一個。在 croit 容器中，必須將它們插入到數據庫中——這是 UI 不允許的。
$ mysql croit
MariaDB [croit]> insert into service values(NULL, 5, 'mds', NULL, 'croit-host-25a', '[mds.croit-host-25a]\nkey = AQA9jn1f7oyKDRAACIJ0Kj8e8D1C4z4p8hU2WA==\n', 'enabled', NOW(), NULL);
[and the remaining keys]然后 croit 在每個集群節點上啟動額外的 MDS 守護程序，這些額外的守護程序甚至在滾動重啟后仍然存在。
最后，要使它們處於活動狀態，需要以下命令：
ceph fs set cephfs max_mds 16
正如預期的那樣，基准測試結果有所改善（每個容器有四個工作進程）：
[RESULT] BW phase 1 ior_easy_write 13.829 GiB/s : time 325.93 seconds
[RESULT] BW phase 2 ior_hard_write 0.373 GiB/s : time 365.60 seconds
[RESULT] BW phase 3 ior_easy_read 16.204 GiB/s : time 278.80 seconds
[RESULT] BW phase 4 ior_hard_read 0.920 GiB/s : time 148.24 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 25.154 kiops : time 594.93 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 13.227 kiops : time 316.73 seconds
[RESULT] IOPS phase 3 find 391.840 kiops : time 48.88 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 153.305 kiops : time 97.61 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 93.870 kiops : time 44.63 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 20.886 kiops : time 716.49 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 28.205 kiops : time 148.53 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 10.496 kiops : time 401.73 seconds
[SCORE] Bandwidth 2.96175 GiB/s : IOPS 42.959 kiops : TOTAL 11.2798看起來每個主機四個 MDS 確實是集群可以有用的最大值。我們不再看到它們長時間消耗 100% CPU 的時期。現在的典型數字是 120% + 80% + 60% + 20%。
行不通的“優化”
額外的 OSDS
理論上，可以使用 OSD 進行相同類型的額外配置。事實上，在過去，一個常見的建議是為每個 SSD 配置幾個 (2-4) 個 OSD。現代 Ceph 提供了不同的解決方案：由“osd op num shards”和“osd op num threads per shard”參數控制的內置 OSD 分片。我們調查了這兩個選項，但發現它們都不能提高整體基准分數。唯一持續改進的指標是“mdtest_hard_stat”，但這被分數的其他部分變得更差所抵消。
調整 OSD 內存目標
Bluestore OSD 使用自己的緩存而不是 Linux 頁面緩存來存儲可能再次需要的副本數據。通常，從其默認值（croit 中 3 GB）增加“osd memory target”可調參數應該可以提高性能，因為這樣 OSD 將從緩存中提供更多服務，而從磁盤中提供更少服務。但是這個特定的基准測試旨在使緩存盡可能無效：它只有在將數據全部寫入后才讀取數據。因此，並且我們已經通過實驗證實，增加 OSD 內存目標對最終得分沒有影響。
調整網絡 MTU
到目前為止，所有基准測試都是使用默認 MTU (1500) 和套接字緩沖區大小進行的。但是，通常建議在高速網絡上將 MTU 設置為 9000，而我們的 100Gbps 網絡當然可以滿足要求。此外，建議增加套接字緩沖區大小的限制和默認值。
我們首先將 OSD 節點和客戶端上的 MTU 增加到 9000。增加 MTU 后，“ior_easy_write”階段的性能確實提升到了 15.163 GiB/s。但是，我們無法完成基准測試，因為“MDS 在修剪時落后”和“MDS 操作緩慢”健康警告，以及由此產生的客戶端黑名單。然后一個 MDS 進入只讀模式，這通常發生在文件系統以某種方式損壞時。
我們繼續使用 iperf 重新測試網絡吞吐量。這比以前更糟。使用 MTU 1500 和默認套接字緩沖區大小，我們能夠使用四個並發連接達到 87 Gbit/s。使用 MTU 9000，我們只有 77 Gbit/s。顯然，網卡在發送時可以有效地執行 TCP 分段卸載，而在接收時則相反，只有 MTU = 1500。
MTU 調整被撤消，不幸的是，文件系統不得不被銷毀並重新創建。
調整 TCP 參數
我們嘗試讓 Linux 內核在 OSD 和客戶端上使用以下 sysctls 將 TCP 緩沖區自動調整為更大的值：
net.core.rmem_max=33554432
net.core.wmem_max=33554432
net.ipv4.tcp_rmem=4096 65536 33554432
net.ipv4.tcp_wmem=4096 131072 33554432結果再次降低了分數：
[RESULT] BW phase 1 ior_easy_write 12.905 GiB/s : time 351.74 seconds
[RESULT] BW phase 2 ior_hard_write 0.382 GiB/s : time 354.09 seconds
[RESULT] BW phase 3 ior_easy_read 16.459 GiB/s : time 275.82 seconds
[RESULT] BW phase 4 ior_hard_read 0.926 GiB/s : time 145.97 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 24.030 kiops : time 637.19 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 12.289 kiops : time 331.97 seconds
[RESULT] IOPS phase 3 find 252.270 kiops : time 76.87 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 95.420 kiops : time 160.47 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 97.223 kiops : time 41.96 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 16.660 kiops : time 919.06 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 15.179 kiops : time 268.76 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 8.265 kiops : time 497.80 seconds
[SCORE] Bandwidth 2.9435 GiB/s : IOPS 33.1105 kiops : TOTAL 9.87222就像任何其他糟糕的調整嘗試一樣，這些設置都被撤消了。
增加 MDS LOG MAX 段
為了防止我們在 MTU = 9000 時看到的“MDSs behind on trimming”健康警告，我們嘗試將“mds log max segments”選項設置為 1280（這大約是警告中 num_segments 峰值的 2 倍）。這嚴重降低了 mdtest 的性能，因此也被撤消了。這是 MTU = 1500 的基准報告：
[RESULT] BW phase 1 ior_easy_write 12.733 GiB/s : time 335.69 seconds
[RESULT] BW phase 2 ior_hard_write 0.374 GiB/s : time 348.14 seconds
[RESULT] BW phase 3 ior_easy_read 17.026 GiB/s : time 256.40 seconds
[RESULT] BW phase 4 ior_hard_read 0.932 GiB/s : time 139.58 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 26.622 kiops : time 575.94 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 12.984 kiops : time 328.36 seconds
[RESULT] IOPS phase 3 find 341.760 kiops : time 57.34 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 107.865 kiops : time 142.15 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 103.463 kiops : time 41.21 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 14.181 kiops : time 1081.19 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 15.855 kiops : time 268.90 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 8.702 kiops : time 493.00 seconds
[SCORE] Bandwidth 2.94821 GiB/s : IOPS 35.5994 kiops : TOTAL 10.2447消除 KSWAPD 瓶頸
在基准測試的 IOR 階段，可以看到“kswapd[01]”內核線程占用了客戶端 100% 的 CPU。“kswapd”線程（每個 NUMA 節點一個）使 Linux 內存子系統對空閑頁面的數量感到滿意。特別是，他們嘗試回收頁面緩存。因此，看起來這些基准測試階段產生了太多臟頁或緩存頁。基准測試提供了一個選項（“ posix.odirect = True”在 [global] 配置文件的部分或特定階段的部分中）通過 O_DIRECT 標志繞過頁面緩存。然而，它實際上使每個 IOR 階段的得分更差，即與預期效果完全相反。
為了使更多的 CPU 時間（實際上是更多的 CPU）可用於頁面緩存回收任務，使用“ numa=fake=8”內核命令行參數在兩個客戶端上創建了一組假 NUMA 節點。結果：這對 IOR 階段沒有幫助（所以 kswapd 畢竟不是瓶頸），而是傷害了“查找”和大多數基於 mdtest 的階段。
[RESULT] BW phase 1 ior_easy_write 13.674 GiB/s : time 342.55 seconds
[RESULT] BW phase 2 ior_hard_write 0.381 GiB/s : time 355.32 seconds
[RESULT] BW phase 3 ior_easy_read 16.784 GiB/s : time 278.14 seconds
[RESULT] BW phase 4 ior_hard_read 0.925 GiB/s : time 146.32 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 23.718 kiops : time 578.62 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 11.818 kiops : time 326.18 seconds
[RESULT] IOPS phase 3 find 261.800 kiops : time 67.14 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 101.016 kiops : time 135.85 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 69.404 kiops : time 55.54 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 18.087 kiops : time 758.75 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 26.474 kiops : time 145.60 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 9.933 kiops : time 390.60 seconds
[SCORE] Bandwidth 2.99932 GiB/s : IOPS 35.3655 kiops : TOTAL 10.2991因此，這也必須撤消。
什么也不做
無所事事不應該受到傷害。它也不應該有幫助，因此它是測試基准結果可重復性的好方法。因此，在撤消所有糟糕的優化后，我們有望重新獲得我們之前看到的高分。讓我們檢查：
[RESULT] BW phase 1 ior_easy_write 13.359 GiB/s : time 455.21 seconds
[RESULT] BW phase 2 ior_hard_write 0.376 GiB/s : time 338.87 seconds
[RESULT] BW phase 3 ior_easy_read 16.634 GiB/s : time 366.70 seconds
[RESULT] BW phase 4 ior_hard_read 0.934 GiB/s : time 136.30 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 24.508 kiops : time 606.63 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 12.352 kiops : time 329.28 seconds
[RESULT] IOPS phase 3 find 288.930 kiops : time 65.53 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 109.363 kiops : time 135.95 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 98.175 kiops : time 41.43 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 18.731 kiops : time 793.72 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 26.504 kiops : time 153.46 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 10.293 kiops : time 397.73 seconds
[SCORE] Bandwidth 2.9722 GiB/s : IOPS 38.4718 kiops : TOTAL 10.6933不完全在那里（主要是因為“發現”），但至少仍然比目前討論的所有錯誤的優化嘗試要好。因此，結論仍然有效。
對整個集群進行基准測試
請記住，我們在每個節點上設置了兩個 NVME 驅動器，因此它們不參與基准測試。現在是把它們帶回來的時候了，因此，也許可以證明底層存儲至少是瓶頸的一部分。
[RESULT] BW phase 1 ior_easy_write 12.982 GiB/s : time 391.63 seconds
[RESULT] BW phase 2 ior_hard_write 0.383 GiB/s : time 349.43 seconds
[RESULT] BW phase 3 ior_easy_read 16.991 GiB/s : time 304.82 seconds
[RESULT] BW phase 4 ior_hard_read 0.923 GiB/s : time 145.14 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 23.997 kiops : time 600.49 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 11.300 kiops : time 335.35 seconds
[RESULT] IOPS phase 3 find 345.570 kiops : time 52.66 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 113.218 kiops : time 127.28 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 99.407 kiops : time 38.12 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 19.261 kiops : time 748.14 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 28.119 kiops : time 134.76 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 10.485 kiops : time 364.02 seconds
[SCORE] Bandwidth 2.97168 GiB/s : IOPS 39.5523 kiops : TOTAL 10.8414嗯，改進是微不足道的。另一方面，每個節點只有四個 OSD（即使我們策略性地選擇它們，使其 NVMe 驅動器的 NUMA 節點與網卡的 NUMA 節點匹配），分數略有降低，因為 NVME 驅動器在 IOR 期間過載階段：
[RESULT] BW phase 1 ior_easy_write 10.775 GiB/s : time 344.10 seconds
[RESULT] BW phase 2 ior_hard_write 0.374 GiB/s : time 359.87 seconds
[RESULT] BW phase 3 ior_easy_read 16.431 GiB/s : time 224.47 seconds
[RESULT] BW phase 4 ior_hard_read 0.925 GiB/s : time 145.59 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 25.422 kiops : time 641.73 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 12.040 kiops : time 324.63 seconds
[RESULT] IOPS phase 3 find 374.070 kiops : time 54.06 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 101.753 kiops : time 160.33 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 78.571 kiops : time 49.74 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 19.180 kiops : time 850.58 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 25.747 kiops : time 151.80 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 9.840 kiops : time 399.77 seconds
[SCORE] Bandwidth 2.79783 GiB/s : IOPS 38.1085 kiops : TOTAL 10.3257因此，雖然存儲量確實會影響性能，但影響很小。這是真正的瓶頸在別處的理論的論據。
更改 PGS 數
正如我們已經提到的，對於這種規模的集群，創建 cephfs_data 池的 PG (512) 少於通常推薦的 (1024)。只是為了測試，我們將池的大小調整為 1024 個 PG。結果是分數略有下降：
[RESULT] BW phase 1 ior_easy_write 13.373 GiB/s : time 349.24 seconds
[RESULT] BW phase 2 ior_hard_write 0.376 GiB/s : time 361.25 seconds
[RESULT] BW phase 3 ior_easy_read 16.557 GiB/s : time 282.76 seconds
[RESULT] BW phase 4 ior_hard_read 0.912 GiB/s : time 148.76 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 20.689 kiops : time 793.92 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 11.058 kiops : time 344.35 seconds
[RESULT] IOPS phase 3 find 333.310 kiops : time 60.70 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 143.516 kiops : time 114.45 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 104.899 kiops : time 36.30 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 19.006 kiops : time 864.21 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 23.765 kiops : time 160.23 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 9.188 kiops : time 417.02 seconds
[SCORE] Bandwidth 2.95176 GiB/s : IOPS 38.4369 kiops : TOTAL 10.6516每個節點有 8 個 OSD。
升級為八達通
作為我們測試的最后一部分，我們安裝了一個夜間版本的 croit 容器，並使用它來將集群升級到 Ceph Octopus（版本 15.2.5）。這確實會導致一些差異：
[RESULT] BW phase 1 ior_easy_write 13.656 GiB/s : time 347.14 seconds
[RESULT] BW phase 2 ior_hard_write 0.332 GiB/s : time 356.28 seconds
[RESULT] BW phase 3 ior_easy_read 16.740 GiB/s : time 282.90 seconds
[RESULT] BW phase 4 ior_hard_read 0.790 GiB/s : time 149.64 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 26.457 kiops : time 436.90 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 12.974 kiops : time 335.61 seconds
[RESULT] IOPS phase 3 find 413.790 kiops : time 38.46 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 117.764 kiops : time 98.16 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 90.990 kiops : time 47.85 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 20.957 kiops : time 551.56 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 25.622 kiops : time 169.94 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 9.646 kiops : time 453.91 seconds
[SCORE] Bandwidth 2.7817 GiB/s : IOPS 40.9341 kiops : TOTAL 10.6708“hard”測試的帶寬更少，“find”和“mdtest_easy_write”的IOPS更高，但最終得分相同。
我們還在 Ceph Octopus 上重新測試了 MTU 9000。這一次，集群在基准測試中幸存下來，並確認了對“ior_easy_write”階段的積極影響，但總體得分有所下降：
[RESULT] BW phase 1 ior_easy_write 15.608 GiB/s : time 343.82 seconds
[RESULT] BW phase 2 ior_hard_write 0.333 GiB/s : time 356.22 seconds
[RESULT] BW phase 3 ior_easy_read 14.657 GiB/s : time 368.92 seconds
[RESULT] BW phase 4 ior_hard_read 0.783 GiB/s : time 151.37 seconds
[RESULT] IOPS phase 1 mdtest_easy_write 25.044 kiops : time 557.53 seconds
[RESULT] IOPS phase 2 mdtest_hard_write 11.682 kiops : time 326.95 seconds
[RESULT] IOPS phase 3 find 394.750 kiops : time 45.04 seconds
[RESULT] IOPS phase 4 mdtest_easy_stat 121.566 kiops : time 114.85 seconds
[RESULT] IOPS phase 5 mdtest_hard_stat 91.986 kiops : time 41.52 seconds
[RESULT] IOPS phase 6 mdtest_easy_delete 19.932 kiops : time 700.49 seconds
[RESULT] IOPS phase 7 mdtest_hard_read 21.683 kiops : time 176.15 seconds
[RESULT] IOPS phase 8 mdtest_hard_delete 8.189 kiops : time 471.37 seconds
[SCORE] Bandwidth 2.77798 GiB/s : IOPS 38.2382 kiops : TOTAL 10.3065因此，我們可以得出結論，11.27 是我們在該集群的 IO500 基准測試中可以獲得的最高分，而 10.84 是我們可以重復獲得的最高分。
剩余的瓶頸
如果沒有解釋為什么測試不能更快，基准報告是不完整的。也就是說，沒有確定無法消除的瓶頸。
“ior_easy_write”階段是獨一無二的，因為它在多個因素上成為瓶頸或幾乎成為瓶頸：使用較少的 OSD，這將是磁盤性能，而使用 MTU 1500，這是網絡吞吐量（在 OSD 上為 80 Gbit/s）。此外，在客戶端上，kswapd 的 CPU 使用可能是一個問題（但我們無法確認這實際上是一個問題）。
禁用 C6 會對幾個階段（“ior_hard_write”、“ior_hard_read”、“mdtest_hard_write”）產生積極影響，也就是說，它們對網絡延遲很敏感。甚至更多（“mdtest_easy_write”、“mdtest_easy_stat”、“mdtest_hard_stat”、“mdtest_easy_delete”、“mdtest_hard_read”）導致 MDS 的 CPU 使用率飆升至 100%，因為 MDS 大多是單線程的，這表明瓶頸。對於兩個階段（“find”和“mdtest_hard_delete”），我們無法確定確切的瓶頸，但它們會受到添加額外 MDS 的積極影響，所以可能就是這樣。
最后的話
Ceph 有許多可調參數。但是，這里只需要其中一個（mds 緩存內存限制）。剩下的工作就是調整 Linux 操作系統、規划集群和創建足夠的客戶端。