В настоящее время я запускаю установку Ceph на 8 серверов, состоящую из 3 мониторов Ceph и 5 узлов Ceph. С точки зрения производительности кластер работает отлично, но со временем узлы начинают менять местами ceph-osd записать на диск. Когда это происходит, я испытываю очень высокую производительность пор, и даже узел, который меняет местами, иногда рассматривается кластером как неработающий. Бег swapoff -a с последующим swapon -a временно решает проблему, но со временем возвращается.
Насколько я понимаю, использование 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
Либо добавьте ОЗУ, либо настройте OSD, чтобы они не использовались так много.
Ваш /proc/meminfo в системе 32 ГБ показывает 26 ГБ памяти, которую ядро отслеживает со страницами 1 ГБ (DirectMap1G). 18 ГБ из которых - активные анонимные страницы. Прочитав немного о том, что Ceph BlueStore обходит файловую систему ядра, становится понятно, что для этого потребуются большие фрагменты анонимной памяти. В отличие от использования файловой системы и разрешения ядру поддерживать большие файловые кеши.
Конфигурация OSD не была предоставлена, но догадываюсь. ~ 26 ГБ памяти разделить на 6 экранных меню - это немного больше 4 ГБ на одно экранное меню. Примерно значение по умолчанию для osd_memory_target который 4 ГБ. Документация этой директивы отмечает, что на практике ядро (Linux) может превышать это значение в зависимости от того, насколько агрессивно оно освобождает страницы. Это намекает на проблему в системе виртуальной памяти: ядро пытается хитро ленить в том, что оно восстанавливает, память не восстанавливается так чисто, как думают люди.
24 ГБ и изменение только для анонимных страниц Ceph составляет 75 +% использования системы на 32 ГБ. Это довольно много. Добавьте другие выделения, такие как файловые кеши и ядро, и не удивительно, что наблюдается подкачка страниц.
Для меня удивительно то, что вы удвоили ОЗУ и все еще видите проблему. Comitted_AS примерно при 28 ГБ это выглядит как рабочая нагрузка в 30 с лишним ГБ. Он не будет выгружен на 60 ГБ, если автоматическое определение размера кеша Ceph не делает что-то умное, как MemTotal увеличивается (не знаю).
Легко попробовать уменьшить osd_memory_target, может быть от 4 до 3 Гб. Освободите несколько ГБ, и, возможно, использование будет достаточно низким, чтобы избежать смерти из-за медленного вывода страниц.
(Другие параметры настройки кэша Ceph задокументированы, но я недостаточно понимаю их или вашу систему, чтобы предложить, что попробовать.)