Что-то странное с кэшем в Linux-дистрибутивах 2. Своп забивается.

а swappiness сикока выставлен?

Пробовал 40, 60, 100, 1 и 0 - никакой разницы, буферы спокойно выезжают в своп.

А не от того ли, что виртуальная машина плотно работает, и надо где-то держать изменения во время дампа?

Вот со всякими дампами и бекапами разговор особый. Установи nocache и вызывай бекап или дамп через него. Например:

nocache vzdump -параметры

интересно, почему всякие цгрупс и лимиты не сработывают? или их нет для таких случаев

Нет. На вм вообще ничего интересного не происходит.

Не, не помогло. Картина та же - буфер непомерно жиреет и лезет в своп. При том что если своп отключить, то всё работает хорошо.

А можно тогда вывод

cat /proc/meminfo

До запуска дампа и когда дамп запущен

https://pastebin.com/R3qz1rbZ

Насколько я понимаю, они ограничивают память самого приложения и никак не влияют на «продукты его жизнедеятельности» в буферах чтения/записи, файловом кеше, в slab’ах/inode’ах ысяких и т.п.

Тут нужен какой-то «garbage collector» уровня системы)

И с nocache, если можно

А, это и было с nocache.
Без nocache требуется ?

Да, для сравнения

Ещё момент. Пропробуйте в процессе дампа или сразу после него сделать

echo 1 > /proc/sys/vm/drop_caches

и потом проверить в cat /proc/meminfo значение строки Inactive(file):

Если там будут большие цифры (пару гигов), то проблема явно в том, что система не может сбросить файловый кеш по каким-то причинам.

Вот пример подобного бага https://bugzilla.redhat.com/show_bug.cgi?id=1411029

с незапямятных времен известен сей феномен: https://www.linuxatemyram.com/

злой oom не приходит и никого не убивает, всё в порядке

Обычно наоборот, ругают киллера за то, что он не приходит, и его отсутствие считают проблемой.

оно и весь своп потратит

И в чем проблема? Это ухудшает качество жизни?

буфер залезает в swap

В своп лезут анонимные страницы, буфер не может лезть в своп.

Весь мозг мне сломал свом постом.

злой oom не приходит и никого не убивает

оом никого не убивает. Убивает оом киллер. оом киллер убивает оом.

free

Ключик -h не учили добавлять?

Сделал https://pastebin.com/XpiuEfJK

Чукча не читатель ?

При том что если своп отключить, то всё работает хорошо.

Ну так работает - не трогай.

буфер непомерно жиреет и лезет в своп

Нет, не буфер лезет.

И в чем проблема? Это ухудшает качество жизни?

Да, все io начинает дико тормозить.

Весь мозг мне сломал свом постом.

Извинити.

Ключик -h не учили добавлять?

Приму к сведению, но понять порядок вещей это не мешает.

Нет, не буфер лезет.

Возможно у меня проблемы с трактовкой free ?
buff/cache больше значения available это норма ?

да. доступная может быть ноль но сотни метров буфера есть. обычное дело.

Бесконечный рост буфера это не норма.

Сделал echo 1 > /proc/sys/vm/drop_caches
Inactive(file): 1135984 kB
https://pastebin.com/62aqu9ee

я что-то пропустил? по ссылке вроде написано, что должно быть и сконцентрированы мысли этой ветки

Таки баг с кешем, похоже. Если дроп кеш не дропает кеш, то тут никакими параметрами ядра не поможешь. Ядро случаем не старое? И какую ФС используете?

Не, дроп кэш этот кэш дропает, но не целиком и своп это естественно не высвобождает.
ФС ext4, ядро 5.3.

Что там написано ? Что постоянно занятый своп это норма ?
Я не припомню такого.

Понять бы как сказать ядру, что мне буффер в свопе не нужен вот совсем. Буфер в свопе реально контрпродуктивно.

Ну вот дропкеш должен освобождать Inactive(file) в ноль. Если этого не происходит, то что-то пошло не так, вот как в баге которую я скинул выше. Собственно в своп залазят реальные данные программ, а не буферы/кеши, но причина этого судя по всему, в том, что буферы/кеши, которые в норме должны удаляться системой вообще без проблем, не могут быть удалены и занимают оперативку, вот в своп данные и уходят.

Занятно, почему по окончании бэкапа занятой памяти остаётся +- столько же ?

Столько же, сколько было до бекапа или столько же сколько во время бекапа?

если верить free и колонке used, то до, во время и после бэкапа разница не очень большая.

В used показывается память, которая занята с точки зрения ОС (фактически это реальное оперативка занятая программами и их кодом). Бекапы и дампы не хранят информацию из файлов в своей памяти. А кеш/буферы должны легко очищаться системой при необходимости. Только этого не происходит. И даже дроп кеш похоже не помогает(

Не, ну если каждую минуту дропать кэш, то в своп оно не вылезает.

Ну тогда и nocache должен работать. Попробуйте запускать с параметром «-n число»:

nocache -n 2 vzdump

Число можно ставить больше, если надо. Тогда nocache будет пытаться «не кешить» несколько раз подряд при каждом запросе. Иногда помогает.

Хоть -n 100500 - не помогает.
Причем такое поведение кэша наблюдается исключительно с vzdump.
Когда кэш наполняется из-за копирования файлов или обычной работы ОС, то он не пытается залезть в своп.

https://forum.proxmox.com/threads/proxmox-is-using-swap-with-lot-of-ram-available.41994/page-2

I finally solved the problem, I was using writeback as KVM HDD cache.

Anyway, right now I set it all my KVM HDD cache to No Cache. 3 days has passed without an RAM issue.

Собственно вот человек тоже делал скрипт с дропом кешей). Потом докопался, что это из-за выставленного writeback кеша у KVM’ки. Поставил No Cache и проблема ушла.

я всегда nocache юзаю.

Только этого не происходит.

С чего взял, чтоэто не происходит?

Буфер в свопе реально контрпродуктивно.

В свопе нет буферов, перестань нести ахинею.

Дай свои настройки vm.

Свопинес в 10 уже пробовал выставлять? А в единицу?

vfs_cache_pressure в десятку выставлял?

Если отключить своп, то во время создания бэкапа я могу запустить ещё 3-4 виртуалки и ничего не дохнет. Что же это тогда такое, если не буфер ?