Ceph 安裝遇到高交換使用率
目前我正在執行 8 個伺服器 Ceph 設置，包括 3 個 Ceph 監視器和 5 個 Ceph 節點。性能方面，集群執行良好，但一段時間後節點開始將程序交換
ceph-osd到磁碟。發生這種情況時，我會體驗到非常糟糕的性能，甚至正在交換的節點有時也會被集群視為已關閉。執行swapoff -a後swapon -a臨時修復問題，但它會及時返回。據我了解，由於記憶體等原因，使用 Ceph 執行高記憶體是正常的，但預計記憶體會被釋放而不是開始交換。
我們嘗試了以下方法：
- 雙倍記憶體，只是需要更長的時間來體驗問題
- 更新核心，沒有結果
- 查看了 Ceph 中的各種設置，沒有找到解決方案
- 將swappiness設置為1，沒有結果只是需要更長的時間才能遇到問題
- 搜尋錯誤，找到舊版本 Ceph 的所有錯誤
有誰知道為什麼會發生這種情況以及如何調解？
根據我們的配置，每台伺服器都有以下規格：
Operating System: CentOS 7 Memory: 32GB OSD's: 6x 900Gb Ceph version: 13.2.5 Mimic Swappiness set to 1發生交換時的目前記憶體：
# free -m total used free shared buff/cache available Mem: 31960 19270 747 574 11943 11634 Swap: 2931 1500 1431交換轉儲：
PID=9 - Swap used: 0 - (rcu_bh ) PID=11077 - Swap used: 4 - (snmpd ) PID=9518 - Swap used: 4 - (master ) PID=7429 - Swap used: 8 - (systemd-logind ) PID=7431 - Swap used: 8 - (irqbalance ) PID=7465 - Swap used: 16 - (chronyd ) PID=7702 - Swap used: 20 - (NetworkManager ) PID=7469 - Swap used: 24 - (crond ) PID=7421 - Swap used: 132 - (dbus-daemon ) PID=1 - Swap used: 140 - (systemd ) PID=3616 - Swap used: 216 - (systemd-udevd ) PID=251189 - Swap used: 252 - (ceph-mds ) PID=7412 - Swap used: 376 - (polkitd ) PID=7485 - Swap used: 412 - (firewalld ) PID=9035 - Swap used: 524 - (tuned ) PID=3604 - Swap used: 1608 - (lvmetad ) PID=251277 - Swap used: 18404 - (ceph-osd ) PID=3580 - Swap used: 31904 - (systemd-journal ) PID=9042 - Swap used: 91528 - (rsyslogd ) PID=251282 - Swap used: 170788 - (ceph-osd ) PID=251279 - Swap used: 188400 - (ceph-osd ) PID=251270 - Swap used: 273096 - (ceph-osd ) PID=251275 - Swap used: 284572 - (ceph-osd ) PID=251273 - Swap used: 333288 - (ceph-osd )/proc/meminfo：
MemTotal: 32694980 kB MemFree: 2646652 kB MemAvailable: 9663396 kB Buffers: 7138928 kB Cached: 545828 kB SwapCached: 23492 kB Active: 24029440 kB Inactive: 5137820 kB Active(anon): 19307904 kB Inactive(anon): 2687172 kB Active(file): 4721536 kB Inactive(file): 2450648 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 3002364 kB SwapFree: 2220284 kB Dirty: 8 kB Writeback: 0 kB AnonPages: 21459096 kB Mapped: 31508 kB Shmem: 512572 kB Slab: 338332 kB SReclaimable: 271984 kB SUnreclaim: 66348 kB KernelStack: 11200 kB PageTables: 55932 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 19349852 kB Committed_AS: 29550388 kB VmallocTotal: 34359738367 kB VmallocUsed: 378764 kB VmallocChunk: 34342174716 kB HardwareCorrupted: 0 kB AnonHugePages: 90112 kB CmaTotal: 0 kB CmaFree: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 248704 kB DirectMap2M: 5963776 kB DirectMap1G: 27262976 kB
要麼添加 RAM，要麼調整 OSD 以減少使用量。
您
/proc/meminfo在 32 GB 系統上顯示 26 GB 記憶體，核心正在跟踪 1 GB 頁面 (DirectMap1G)。其中 18 GB 是活動的匿名頁面。在閱讀了一些關於 Ceph BlueStore 繞過核心文件系統的資訊之後，這很有意義，它需要大量的匿名記憶體。與使用文件系統並讓核心維護大型文件記憶體相反。沒有提供 OSD 配置，但我可以猜到。~26 GB 記憶體除以 6 個 OSD 比每個 OSD 多 4 GB。大約預設為
osd_memory_target4 GB。該指令的文件指出，實際上（Linux）核心可能會超過這個值，具體取決於它回收頁面的積極程度。這暗示了虛擬記憶體系統的一個困難：核心試圖巧妙地在它回收的東西上變得懶惰，記憶體並沒有像人們想像的那樣乾淨地回收。24 GB 和 Ceph 匿名頁面的變化是 32 GB 系統的 75+% 使用率。這是相當高的。添加其他分配，如文件記憶體和核心，觀察到分頁並不令人驚訝。
令我驚訝的是，您將 RAM 翻了一番，但仍然發現問題。
Comitted_AS大約 28 GB 讓我看起來像是 30 GB 的工作量。它不會在 60 GB 時分頁，除非 Ceph 自動記憶體大小在MemTotal增加時做一些聰明的事情（我不知道）。一個簡單的嘗試是減少
osd_memory_target，也許從 4 GB 到 3 GB。釋放少量 GB，並且可能使用率會足夠低，以避免因緩慢的頁面輸出而死亡。（記錄了其他 Ceph 記憶體調整參數，但我不了解它們或您的系統不足以建議嘗試什麼。）