Заставить систему использовать swap.

имхо кэш по определению низшего приоритета и его будут вытеснять любые пользовательские данные

компрессия ram

ускорения отзывчивости

Лолчто.

Когда я загрузил в общей сложности 1500 доп. памяти засчет сжатия, странички браузера все еще нормально открывались, все работало достаточно хорошо. В то же время дисковый кэш был полностью истощен, в связи с этим к примеру повторное открытие тех или иных программ шло всегда с жесткого диска. Вот было бы не плохо, если на 1000МБ уже начал заполняться SWAP. Вообще насколько я понимаю, через пару дней работы устаревшие страницы должны быть скинуты в SWAP из за swappiness=100?

Еще обнаружил проблему. Если очень быстро пожирается память (хром запусить с 50вкладками) то нетбук может подвиснуть когда он вдруг пожирает 1900 + 100 мегов кэш + он пытается перейти в своп, а для расширения ZRAM места уже нет. В итоге может зависнуть на 10 минут, а потом показать что на оперативе занято 1600 и в свопе еще 800. Браузер жмется очень хорошо, я сейчас пробую залить ZRAM в 4 гига под завязку. По данным тех, кто тестил, должно сжиматься в 5 раз. И вот поэтому и хочется побольше кэша...

По вопросу - нет, так нельзя (Lordwind прав).

Но вообще хочу заметить, что:

• zram - не самая хорошая идея для swap-а. Есть такая вещь, как frontswap/cleancache; точно не знаю, как настраивать, но ты погугли. По сути, это то же самое, только не забивает гвозди микроскопом (а также не требует настройки микроскопа кувалдой).
• vfs_cache_pressure = 0 делать нельзя. Если вкратце, то этот параметр отвечает за то, насколько сильно выгружать из кэша «высокоуровневые» записи (т. е. inode и dentry) по отношению к низкоуровневым (т. е. собственно страницам). Значение 0 означает «никогда не выгружать inode и dentry». Вообще никогда.

А, вот. frontswap/cleancache сами по себе являются фронт-эндами; ещё надо включить zcache.

Я тестил с 0, и оно выгружало. Значение vfs_cache_pressure=10 будет приемлемо? Насчет cleancache «Для подсистем ядра, интенсивно использующих кеширова-ние, теперь реализован новый тип кеша Cleancache. Он реализует хранилище, содержимое которого может быть уничтожено в любой момент без возможности восстановления. Типичным примером использования Cleancache является кеш файловых систем, предназначенный для ускорения операций ввода-вывода, но в случае уничтожения легко восстанавливаемый с помощью повторного чтения данных с диска. Благодаря использованию Cleancache, ядро сможет без задержек освобождать кеш, когда в системе появится дефицит памяти, что благотворно скажется на производительности. »

Это все почти что я нашел в русскоязычном сегменте, да и в англоязычном не особо есть какая то инфа, только коммиты ядра гуглятся :) Идея Zram для меня была еще в том, что в случае надобности памяти на самом деле становится больше. + неиспользуемые страницы которые сбрасываются в своп сжимаются. Т.е. в случае обращения к ним они будут пусть сжаты, но не будут на жестком диске лагать. Я не совсем пойму Cleancache это технология быстрой очистки дисковых кэшей, или это специальная технология для создания этого дискового кэша?

PS. обнаружил немного другое описание на лоре «zcache врубается в основном при большой нагрузке. когда поступает запрос на выкидывание данных из файлового кэша, они сжимаются lzo (а в теории и не только) и остаются в памяти. Получаем некислый профит в i/o за счет небольшой дополнительной нагрузки на процессор.»

Т.е. по сути кэш висит нормально, а при потреблении он сжимается...интересно. Ведь можно это вместе с Zram использовать. Еще кстати в идеях к ZRAM было использование большого RAM диска для запуска чего либо жрущего оперативу. Та же сборка ядра к примеру в tmpfs в кучу потоков.

Я сделал modprobe zcache на 3.11 Получил

[  191.918678] zcache: module is from the staging directory, the quality is unknown, you have been warned.
[  191.919205] zcache: using lzo compressor
[  191.919395] zcache: created ephemeral local tmem pool, id=0
[  191.919403] zcache: created ephemeral local tmem pool, id=1
[  191.919408] zcache: created ephemeral local tmem pool, id=2
[  191.919411] zcache: cleancache enabled using kernel transcendent memory and compression buddies
[  191.919416] zcache: created persistent local tmem pool, id=3
[  191.919420] zcache: frontswap enabled using kernel transcendent memory and compression buddies

Еще кстати оно у меня модулем висит.

[bupyc@bupyc-notebook ~]$ cat /proc/config.gz | gzip -cd | grep ZCACHE
CONFIG_ZCACHE=m
# CONFIG_ZCACHE_DEBUG is not set
[bupyc@bupyc-notebook ~]$ cat /proc/config.gz | gzip -cd | grep CLEANCACHE
CONFIG_CLEANCACHE=y
[bupyc@bupyc-notebook ~]$ cat /proc/config.gz | gzip -cd | grep FRONTSWAP
CONFIG_FRONTSWAP=y

Да, должно работать. Можно проверить, заглянув в /sys/kernel/debug/{frontswap,cleancache}.

(должна быть примонтирована debugfs, т. е. mount -t debugfs none /sys/kernel/debug).

Cleancache и frontswap - это, грубо говоря, внутриядерные интерфейсы к системам сжатия вроде zcache.
Поэтому zcache вполне может быть модулем, а первые две - нет (там нечего собирать в модуль, это просто несколько #ifdef'ов в коде ядра).

Окей, если, как говоришь, выгружает - то юзай. Я просто такими извращениями не занимаюсь :), и смотрю исключительно по докам на sysctl (https://www.kernel.org/doc/Documentation/sysctl/vm.txt).

Смотри. В обычном режиме всей памятью управляет ядро. То есть, оно её делит на память приложений и кэша (очень грубая аналогия, но всё же) и само следит за временем жизни объектов в кэше (LRU и всё такое), в зависимости от того, насколько они нужны (т. е. есть «чистые» страницы, которые в точно таком же виде есть на диске, и «грязные», которые с момента последней записи изменились).

A cleancache и frontswap - это парные интерфейсы, позволяющие передать управление кэшем какому-то стороннему коду по принципу чёрного ящика.
У этих интерфейсов ровно две операции: «положить страницу в кэш» и «взять страницу из кэша». Отличия только в гарантиях:

• cleancache: интерфейс для чистых страниц, которые не страшно потерять. «Положить» срабатывает всегда, «взять» - может не сработать.
• frontswap: интерфейс для грязных страниц, которые нельзя потерять. «Положить» может не сработать (тогда ядро юзает стандартные методы), но если оно сработало, то операция «взять» также должна выполниться.

И, наконец, zcache - это реализация интерфейсов cleancache/frontswap, которая делает ровно одно: сжимает то, что в неё пишут.

Т.е. по сути кэш висит нормально, а при потреблении он сжимается

Да, frontswap и cleancache используются только тогда, когда ядру не хватает места в стандартной памяти, т. к. последняя всё же быстрее.

Еще кстати в идеях к ZRAM было использование большого RAM диска для запуска чего либо жрущего оперативу.

По идее, для этого он и придумывался.

А как вы относитесь к zramswap на сервере? Слышал что спасает от ситуаций куда под нагрузкой вся бд перекинулась в своп, а он в свою очередь на жестком диска и дает большой лаг. В то же время эти данные хорошо жмутся в итоге можно пережить скачек нагрузки и не терять в производительности.

Кстати, вот у меня 6 гигов рамы, занято 1 гиг. Сжатие кэша будет когда я начну еще использовать память, или же при использовании файлов кэш сам будет сжиматься?

А как вы относитесь к zramswap на сервере? Слышал что спасает от ситуаций куда под нагрузкой вся бд перекинулась в своп, а он в свою очередь на жестком диска и дает большой лаг.

Если так, то, безусловно, swap на zram оправдан... Только обычный swap лучше тоже иметь, с меньшим приоритетом.

Кстати, вот у меня 6 гигов рамы, занято 1 гиг. Сжатие кэша будет когда я начну еще использовать память, или же при использовании файлов кэш сам будет сжиматься?

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

Т.е. причина - кэша уже много загружено и свободного места для нового нет. Будет сжиматься самый старый?

«Если так, то, безусловно, swap на zram оправдан... Только обычный swap лучше тоже иметь, с меньшим приоритетом.»

Как мне кажется таки для любой машины ZRAMSWAP полезен, что либо утечет - будет больше времени на килл процесса, пока не утелко в своп на диске. + таки неиспользуемые страницы тоже идут в своп, полезно если они будут сжаты. Вот кстати еще вопрос, при swappiness=60 страниц должны переходить в своп, если из 6 гигов используется 1-3 гига обычно? Или же это произойдет когда памяти станет еще меньше?

Т.е. причина - кэша уже много загружено и свободного места для нового нет. Будет сжиматься самый старый?

Вроде того. Самые старые чистые страницы, вместо того, чтобы быть дропнутыми, отправляются в cleancache, а самые старые грязные (и просто пользовательские, насколько я понимаю) страницы, вместо того, чтобы быть выгруженными в swap, отправляются в frontswap. Вот здесь это описано более детально: https://www.kernel.org/doc/Documentation/vm/frontswap.txt

Поэтому, кстати говоря, frontswap+zcache приближенно равно zramswap (только оно само собой управляет). Я склоняюсь к тому, что frontswap+zcache лучше, чем zramswap, т. к. стандартные алгоритмы swap-а в Linux вряд ли могут предполагать, что запись страницы в swap в условиях нехватки памяти на самом деле ведёт к аллокации дополнительного куска этой самой памяти (под сжатые данные).

Насчёт vm.swappiness - хрен знает, посмотри в код, если сильно интересно.

" т. к. стандартные алгоритмы swap-а в Linux вряд ли могут предполагать, что запись страницы в swap в условиях нехватки памяти на самом деле ведёт к аллокации дополнительного куска этой самой памяти (под сжатые данные)."

Ну по сути Linux должен предполагать, если создан RAM диск со сжатыми данными, то он может в процессе работы заполняться. На этот случай кстати вроде есть дополнительное место в RAM которое висит всегда свободное, т.е. по сути при передаче страниц из RAM в ZRAM будет достаточно места, чтобы все не зависло.

Еще кстати интересно, есть ли менее костыльный метод. Т.е. чтобы ядро самом сжимало просто менее используемые страницы в памяти. При этом удобно будет, если можно будет настроить поведение всего этого дела. Например браузер - пусть сжимается побольше, а системные службы пусть не сжимаются. Мб есть какой нибудь способ насильно скинуть память браузера в своп к примеру? Есть же тот же s2disk. Он по сути всю память дампит в своп, а потом при загрузке большая часть памяти остается в свопе, где то больше половины там висит. Т.е. он как то таки перемещает страницы туда.

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

Каким же образом он это узнает? Я неоднократно встречался с OOM и просто терминальными «зависаниями всего» при работе с zramswap.

кстати вроде есть дополнительное место в RAM которое висит всегда свободное

Нет такого.

Еще кстати интересно, есть ли менее костыльный метод. Т.е. чтобы ядро самом сжимало просто менее используемые страницы в памяти.

Для этого и придумали cleancache и frontswap. Само ядро (т. е. базовые алгоритмы mm) так делать никогда не будут - не тот уровень абстракции. К тому же, нет смысла сжимать что-то, пока свободная память есть.

Мб есть какой нибудь способ насильно скинуть память браузера в своп к примеру?

Нет, per-process управление свопом отсутствует. Меня самого это интересовало.

s2disk - это гибернация, и там совсем другие принципы.

Я верно понял, cleancache - это когда память кончается, кэш сжимается. А frontswap это когда память кончается сжимаются страницы? И эти же страницы остаются в памяти или же идут в своп?

Я кстати вот что нашел http://lkml.indiana.edu/hypermail/linux/kernel/0407.0/1119.html Тут реквест от 2004 года к резерву под рут нужды. Где то читал, что таки резервируется память, она позволяет выполнять например Sysrq вызовы.

Я таки тестил когда cleancache+frontswap+zramswap заметил интересную вещь. Таки когда я загрузил вроде как обычно 2 браузера и кучу вкладок, оно дошло где то до 1600 и в своп ушло ну может 100 мегов. При этом внешне кэш продолжал работать (выгрузка загрузка браузера быстрее) Т.е. видимо frontswap сжимает память, а потом если таки не умещается оно идет в своп, и в моем случае этот же своп еще сжимается в памяти...эм :)

http://zenway.ru/forum/viewtopic.php?id=89 нашел занимательную историю успеха. Кстати сейчас в виртуалке крутится дебиан на 3.2 прикрутил вручную zram, отключил обычный своп, понизил vfs_cache_pressure повысил swappiness - профит. Стало работать намного лучше.

Хм... Да, по ходу, резервируется: vm.min_free_kbytes. Окей. Но это не отменяет того, что я часто попадал в OOM, когда юзал zramswap.

cleancache (+zcache) - сжимаются «чистые» страницы кэша, вместо того, чтобы быть просто выкинутыми из памяти (т. к. они в том же виде есть на диске, и хранить их в памяти необязательно).

frontswap (+zcache) - сжимаются «грязные» страницы кэша и страницы памяти приложений, вместо того, чтобы быть записанными в swap.

Что потом делается со сжатыми - они просто лежат в памяти. Но когда zcache перестаёт хватать памяти для хранения сжатых страниц, начинает использоваться обычный swap. И вот уже в этом случае данные, сжатые zcache, могут попасть и в swap (точнее, в swap попадут страницы, в которых лежат сжатые данные).

cleancache+frontswap+zramswap

А зачем ты тестил две взаимоисключающие системы (frontswap и zramswap)?

Это больше похоже чтоб наверняка. Что то с zramswap как то более видно результат, когда у в свопе на RAM лежат данные.

Опять таки, вот интересно, уже например забито у меня 1600 из 2000, в своп оно только только начнет записываться. В общем еще буду тестить. Опять попробую запустить KDE с кучей окон и программ в обоих случаях. Но мне кажется frontswap работает в более лояльном режиме. Т.е. если zramswap в любом случае будет пытаться сжимать, то frontswap скорее всего будет стараться оставлять значительный запас и почти сразу уходить в обычный swap. Или же frontswap сможет к примеру сжать сначала новые поступающие страницы, а потом сжать еще и старые которые уже записаны в память? Т.е. через frontswap можно ли добиться момента, когда ВСЯ память или хотя бы её 90% сжаты? (тот же zram по сути позволит использовать где то 1500 мегов несжатые и еще 1500 сжатых, хотя по сути если сжать еще 1500 имеющихся, можно будет записать еще больше данных)

[root@bupyc-notebook bupyc]# cat /sys/kernel/debug/{cleancache,frontswap}/*
2188624
3026281
2067565
108156
7113
68
14820
130830
[root@bupyc-notebook bupyc]# free
             total       used       free     shared    buffers     cached
Mem:       5496440    5362448     133992          0       2892     245456
-/+ buffers/cache:    5114100     382340
Swap:      2748208     538904    2209304
[root@bupyc-notebook bupyc]# swapon -s
Filename				Type		Size	Used	Priority
/dev/zram0                             	partition	687052	134760	100
/dev/zram1                             	partition	687052	134772	100
/dev/zram2                             	partition	687052	134680	100
/dev/zram3                             	partition	687052	134684	100

Вот пример. по сути frontswap уже сдулся - т.е. как бы данные уже начали заливаться в своп. При этом все на пределе по сути, но машина работает отлично! Я запустил дота 2, она не лагает, видео работает отлично, активность диска минимальна.

При этом в данный момент настройка Zram достаточно низка - половина RAM. Хотя многие говорят, что к примеру браузеры жмутся в 5 раз. Из 6 занятых гигов, где то 3 гига потребляют браузеры.

Кстати, достаточно интересно, что при размере кэша в 200 мегабайт (видимо достаточно хорошо сжат) машина остается очень шустрой, нет разницы свободно 6 гигов или нет.

Мм интересно, начав закрывать браузеры и закрыв хром все повисло. Frontswap случайно не разжимает память если она появляется? А то видимо он попробовал, а там Zram еще лежит. Хотя возможно что и не в этом причина, я за 10 секунд до этого закрыл доту 2. У меня до этого были фризы, когда я доту 2 открывал не в том разрешении (catalyst) Тут я тыкнул закрыть и перешел к другому столу в awesome... Мм... Но врядли все таки из за Zram зависло, ибо в момент закрытия хрома было свободно еще 3 гига оперативы, т.к я закрыл Firefox и выгрузил доту 2.

Надо бы мне завести еще своп и добавить памяти. Zcache случайно при сжатии кэшей не размещает их в виде обычный памяти приложений? Или же считается как кэш? А то как то слишком быстро кончилась память...

Я вот двух вещей не могу понять. Во-первых, зачем ты хочешь, чтобы «ВСЯ память или хотя бы её 90% сжаты»? Если свободная память есть - то сжимать её не надо, и обратного поведения добиться можно только через дикие костыли.

Во-вторых, почему ты ждёшь стабильности, используя две _технически_ взаимоисключающие подсистемы - zramswap и frontswap+zcache? У них общий аллокатор памяти, а это означает, что ты влёгкую наткнёшься на рекурсию вида «память, выделенная zcache, отправляется в swap и попадает в zram, который делит один и тот же кусок памяти с zcache». И, видимо, уже наткнулся.

«Я вот двух вещей не могу понять. Во-первых, зачем ты хочешь, чтобы «ВСЯ память или хотя бы её 90% сжаты»? Если свободная память есть - то сжимать её не надо, и обратного поведения добиться можно только через дикие костыли.»

Ну имелось скорее в виду, что когда уже нет памяти, чтобы она сжималась дальше. Т.е. если сжать все все то в 6 гигов может уместиться 12 гигов. Так вот проблема в чем, если при не очень большом наполнении памяти, она вдруг идет в swap, значит таки frontswap неэффективен?

хм... Сохранил тему. Давно не видел постов, в которых автор умудрился столько раз СРАЗУ поделить на ноль.

Говорю же - отключи zramswap, блин.

У меня сейчас ядро 3.13, появился Zswap, исчез zcache? Куда его дели? Он же как бы сжимал отдельно кэш и страницы памяти. А Zswap как то больше на Zramswap похож, только в ядре.

zcache и zswap - бэкенды к cleancache/frontswap, а следовательно, в итоге нужны для одного и того же.
Костыль по имени zramswap тут никоим боком.

Касательно zcache:

commit 96256460487387d28b8398033928e06eb9e428f7
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Aug 12 15:07:49 2013 -0700

    staging: zcache: delete it
    
    zcache is obsolete and not used anymore, Bob Liu has rewritten it and is
    submitting it for inclusion through the main -mm tree, as it should have
    been done in the first place...
    
    Cc: Bob Liu <lliubbo@gmail.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Kyungmin Park <kmpark@infradead.org>
    Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

То есть zcache теперь интегрирован в ядро полностью? Или как? Насчет frontswap я разобрался уже. К слову в 3.13 в дебаг все еще присутствуют файлы cacheclean и frontswap.

Ты путаешь уровни.

• cleancache и frontswap - фронтенды; их никто не убирал и убирать не собирается;
• zcache - бэкенд - временно выпилили из ядра, поскольку код был говно;
• zswap - другой бэкенд - в то же время добавили в ядро.

Ок, так с чем сейчас работает cleancache если zcache выпилен? Или cleancache и frontswap являются фронтендами для zswap в данный момент?

Или cleancache и frontswap являются фронтендами для zswap в данный момент?

Да, именно так. Это всё одна и та же подсистема - так называемая «трансцендентная память».