☰

Ceph 安装遇到高交换空间使用率

tag-icon • tag-icon linux centos storage ceph
Ceph 安装遇到高交换空间使用率

目前，我正在运行一个由 3 个 Ceph 监视器和 5 个 Ceph 节点组成的 8 服务器 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

答案1

要么添加 RAM，要么调整 OSD 以减少使用太多内存。

在/proc/meminfo32 GB 的系统上，内核正在跟踪 26 GB 的内存，其中有 1 GB 的页面（DirectMap1G）。其中 18 GB 是活跃的匿名页面。在阅读了一些有关 Ceph BlueStore 绕过内核文件系统的内容后，这很有意义，因为它需要大量的匿名内存。而不是使用文件系统并让内核维护大型文件缓存。

没有提供 OSD 配置，但我可以猜测。~26 GB 内存除以 6 个 OSD，每个 OSD 略大于 4 GB。大约是默认的osd_memory_target4 GB。该指令的文档注意到实际上 (Linux) 内核可能会超过这个值，具体取决于它回收页面的积极程度。这暗示了虚拟内存系统存在一个难题：内核试图巧妙地偷懒回收内存，内存回收并不像人们想象的那么干净。

仅 Ceph 匿名页面的 24 GB 变化就使 32 GB 系统的利用率达到 75% 以上。这相当高。加上文件缓存和内核等其他分配，观察到页面调出也就不足为奇了。

令我惊讶的是，你把 RAM 增加了一倍，但问题仍然存在。大约 28 GB 的内存对我来说看起来像是 30 多 GB 的工作负载。除非 Ceph 自动缓存大小在增加时做了一些巧妙的事情（我不知道），Comitted_AS否则它不会在 60 GB 时分页。MemTotal

一个简单的办法是减少osd_memory_target，比如从 4 GB 减少到 3 GB。释放一些 GB，利用率可能就会低到足以避免因页面输出缓慢而导致的崩溃。

（其他 Ceph 缓存调整参数都有记录，但我对它们或您的系统了解不够，无法建议您尝试什么。）

相关内容