а вы можете подключиться к дедику напрямую по ssh и запустить htop?

вот там в htop если жёлтенькая полосочка занимает всю RAM, это ничего страшного.

а если зелёненькая, то такого быть не должно, и стоит обратить внимание на список процессов.

а вы можете подключиться к дедику напрямую по ssh и запустить htop?

Разумеется могу)

а если зелёненькая, то такого быть не должно, и стоит обратить внимание на список процессов.

This, к сожалению.

ЧСХ, почему-то процесс /usr/bin/kvm крутит мою VM в трёх экземплярах, т.е. таких процессов 3 :-)

Не знаю норма ли это)

Пока не могу понять, где косяк.

Одно известно точно, такая ситуация возникает при нагрузке на VM, выжирается память хоста и не возвращается.

Это все при том, что Memory ballooning у меня для той виртуалки включён.

Покажи вывод free -m на Proxmox.

free -m
              total        used        free      shared  buff/cache   available
Mem:          32048       13775       18116          51         156       17909
Swap:             0           0           0

Это уже после перезагрузки ноды, за пару часов наберёт опять гигов 20.

Лично я пока грешу на распиаренную ZFS, в целом не знаю.

Дополню, что на этом же хосте висит «пустая» виртуалка с Nextcloud, на неё выделенно 8Гб из которых занято 600Мб, т.е. погоды она не делает.

Повторюсь, что было замечено эмпирически: только стоит увеличиться потреблению RAM и использованию I/O VM, тут же начинает расти потребление RAM на хосте.

Причем расти заметно и быстро до значений 20+ Гб.

Пошел читать про ОЗУ и ZFS.

https://pve.proxmox.com/wiki/ZFS_on_Linux#_limit_zfs_memory_usage

Попробуем.

если зелёненькая, то такого быть не должно, и стоит обратить внимание на список процессов.

кэш ZFS идентифицируется именно как «зелененькая полосочка». Подозреваю проблема ТСа именно в этом - нужно урезать размер кэша

Update: тред не читай - сразу отвечай

Я не помню, что там в Linux, потому начни с sysctl -a | grep zfs. В первую очередь смотри на ARC. По линуксовым oid’ам ничего обещать не могу, но если что — пинай, может что вспомню.

Proxmox и ZFS. Производительность (комментарий)

Первый совет отсюда о том же самом.

Досинкаются письма. Снова перезагружу ноду, скину pveperf, ближе к вечеру.

Для порядка :-)

Да, похоже на то.

ок

sysctl -a | grep zfs

kernel.spl.gitrev = zfs-0.8.3-0-g9bb3d57b0-dirty

Пошел урезать кеш.

Я про поиск oid’ов, отвечающих за ARC и другие кэши.

Если в ZoL так же как и в FreeBSD, то смотри на vfs.zfs.arc_max для начала.

free -m

Покажи вывод free -m в момент описываемой проблемы, а не сразу после перезагрузки.

Да, уже понятно, что это ARC cache, смысла показывать нет.

Ограничил его, потребление ОЗУ ожидаемо уменьшилось.

Но ЧСХ, все равно на 2 Гб больше суммы ARC cache + VMs. Но это уже, видимо, кеш самой ОС.

Апну тему

А есть вообще реализации репликации на уровне ФС, кроме OpenAFS, GlusterFS и прочего?

Что ты подразумеваешь под репликацией? Хранение нескольких копий каждого экстента/кластера? Это есть много где. А вот насчет хранения нескольких копий, да чтоб они при этом были не просто так, а на разных физических устройствах - это уже список ощутимо поуже будет.

К примеру, у ZFS в свойствах dataset-а есть параметр copies, но на него НЕЛЬЗЯ полагаться в качестве отказоустойчивости при отказе одного из устройств пула

Для этого в ZFS есть vdev

Если ищешь распределённую ФС, то сейчас это практически всегда ceph. Порог вхождения повыше, чем у GlusterFS, но дальше длинный список преимуществ.

Ограничил его, потребление ОЗУ ожидаемо уменьшилось.

ARC автоматом вытесняется при нехватке памяти вплоть до zfs_arc_min, которое обычно стоит на нуле.

Если у тебя основная часть I/O идёт на ZFS, то лучше память отдать под ARC, чем линуксовые кеши.

А вот насчет хранения нескольких копий, да чтоб они при этом были не просто так, а на разных физических устройствах.

this

Ну понятно, или ZFS или Ceph, третьего не дано.

Спасибо.

ок, т.е. пугаться, что занято больше половины ОЗУ не стоит?