Используете ли вы zswap или своп в zram?

В windows 7 был внедрён кеш записи на диск, который существенно ускорил дисковые операции. Чтобы что?

Имеет смысл любой компрессор, работающий быстрее диска и возможно даже чуть медленней. Там могут быть сильно разные сценарии и разные настройи. Например более высокая компрессия должна выиграть когда свопятся малые порции рамы, например при работе с кучей небольших сайтов. Просто тупо больше влезет. А быстрый компрессор вроде как должен лучше сработать когда надо впихнуть невпихуемое - например компиляция огромных пакетов в кучу потоков.

А ещё есть настройка «сбрасывать в своп по хх страниц». Я перешёл на крупные пакеты и оно теперь работает как дополнительный кеш свопа. Думаю побочный эффект - компрессор, работа приложения и собственено свопинг распаралеливаются и меньше зависят друг от друга по задержкам.

Собственно я не могу определиться, lzo или lz4? В реальном использовании не вижу разницы! НА малине, со слабым цпу!

что ты пытаешься мне доказать? у меня только zram, но сжатие lzo чтобы не было даже микролагов

Если хотите так - используйте zram+backind_dev - при поднятии вкладок браузера из свопа даже быстрее выходит.

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

То что там даже deflate будет лучше чем ниего. А вот с lzma уже не прокатит.

А без микролагов - ну извини, это как свопиться. Я могу открыть 4 .pdf в Окуляре с агресивной отрисовкой и положить свопинг несжимаемыми данными.

Подожди, у тебя же вроде есть что то из довольно старых компов? А если ещё tmpfs, то как это сочетается с «своп почти всегда пустой»?

Впихнуть в неё 150% о её физического объёма. И поэкономить при этом ресурс своп-ссд. Ну и ещё немного время.

Там могут быть сильно разные сценарии и разные настройи. Например более высокая компрессия должна выиграть когда свопятся малые порции рамы, например при работе с кучей небольших сайтов.
А быстрый компрессор вроде как должен лучше сработать когда надо впихнуть невпихуемое - например компиляция огромных пакетов в кучу потоков.

Такая фича есть в zram с неданих пор, разный алгоритм сжатия для разных условий. Писал об этом ранее. Кто использует zram-generator, могут попробовать.

Так, и вот у нас появились 4 оригинала, которые используют их одновременно...

я посмотрел сервис. у меня lz4, не lzo. lz4 сжимает намного хуже zstd, но сжимает на порядок быстрее. у lzo скорость распаковки намного медленее чем lz4. у меня не уходит система в своп… если только ведроид студию не запускать, тогда текущая джава выжирает всю память при долгой работе. ставь приложения из flatpak. хватит компилировать

Что то я совсем другое вижу. writeback это фишка сортировщика, полезно, ещё один шаг zram от своего прямого назначения в сторону того чтобы стать ещё одним zswap. recompress это перепаковать устройство если оно уже создано, а не использовать разные алгоритмы в разных сценариях. zswap тоже может «сменить» алгоритм компрессии в процессе работы, но только для новых сжимаемых стрнаниц. Это всё про поиграться-потестировать.

Ну да, отлично, казалось бы, lzo и lz4 должны вести себя принципиально по разному. Ну и где? В реальной работе, особенно с браузеромм, они почти идентичны потому что всё это происходит в фоновом потоке, а своп-подсистема достаточно умна чтобы сжимать холодную а не горячую память.

recompress это перепаковать устройство если оно уже создано, а не использовать разные алгоритмы в разных сценариях

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

(Ядро должно поддерживать CONFIG_ZRAM_MULTI_COMP)

Но это все затеял «инженер Google», а к ним мы относимся с пиететом, вроде, как бы, херни не будут делать.

?!

Инжинер Гугла это уже как британские учёные, только хуже.

Да, и прочитав (доки ядра) я понял что угадал. Оно реально будет чесать дополнительной очередью «охлаждения» страниц, и потом повторно разжимать и сжимать страницу более мощным алгоритмом в надежде выиграть ещё чуть-чуть процентов от 4Кб. Маразм полнейший, особенно если на компе уже висит многопоточная нагрузка. Одни только операции по шине памяти могут дать обратный эффект!

В windows 7

Протухшеоффтопопроблемушки, не?

как британские учёные

Соотечественник, Sergey Senozhatsky.

У меня FreeBSD, нет у нас этих ваших zram/zswap. Но я их успел пощупать, когда был гентушником.

Не, предложение вренуться во времена ХР и Висты с просадкой скорости i/o в разы от появляения пары потоков. Ну а чо, работало же! Зачем какие то ускорители и оптимизаторы внедрять?

Ты свои «предложения» как-то формулируй яснее. А так все эти «ускорители» плюс-минус разговоры в пользу бедных, особенно на домашнем компе, который у большинства местных админов лолхоста большую часть времени просто греет атмосферу, когда включен — нагрузить его им тупо нечем. А если «с понтом» — то у них там любой модный в этом году хайп тупо делает GIGO, выхлоп от которого опять же примерно «тепловой» и по температуре и по энтропии и качество его от «скорости IO» не зависит никак. Они его просто больше в единицу времени порождают. Теплового шума. И еще их «сетап» любой маркетинговой крутизны собирает пыль в любом состоянии. Поэтому задрочки про зрамы, так же как про рейды ранее и про лвмы с бтрфсами в среднем дают по больничке выхлоп на уровне погрешности, просто спускают в свисток избыток энергии «первой половины детства», пока любители этого всего не женятся.

На системе с маленьким кол-вом оперативной памяти и при медленном диске использую zswap (z3fold, zstd), и это просто отличное решение, экономящее кучу ресурсов. Zram кажется перемудреным костылем, требующих слишком инвазивно-агрессивных настроек того же swappiness.

А если ещё tmpfs, то как это сочетается с «своп почти всегда пустой»?

Во-первых у меня нет «сред». Ни KDE ни Гнома. А есть icewm. Это уже само по себе настолько экономит память что даже на четырех гигах можно рисовать небольшую плату в KiCAD и своп будет пустой. В результате я стал лениться включать большой комп с 16 гигами и много чего делаю на маленьком.

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

В результате я стал лениться включать большой комп с 16 гигами и много чего делаю на маленьком.

А включишь zswap и на маленьком будешь все делать, и даже не заметишь разницы с большим. )

upd. Сам использую zram, но все больше убеждаюсь, что он не для всех, в плане эффективной настройки. Zswap попроще, включил и забыл, главное, чтобы своп-раздел/файл был.

А зачем оно нужно? Память экономить?

Когда-то сжатие страниц перед помещением в дисковый swap обосновывалось медленностью механических дисков и их интерфейса. Вот чтобы сократить объемы этого медленного дискового ввода-вывода и сжимали. А ОЗУ было мало поэтому ситуации востребованности свопа на диске возникали довольно часто. Сейчас и диски стали не механические и обмен с ними быстрее и оперативной памяти можно поставить много и не разориться. Так что сжатие это осталось актуальным только в каких-то весьма особых и экзотических случаях.

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

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

А включишь zswap и на маленьком будешь все делать, и даже не заметишь разницы с большим.

Если свап-раздел и так примерно всегда пустой то заметного эффекта от zswap не будет. А большой комп - он процессором больше маленького. Иногда бывает актуально когда надо что-то посчитать. Например OpenSCAD при некоторых операциях очень в проц упирается. Считать всякие скругления через векторную сумму Минковского - это долго. Вот только последний раз оно мне потребовалось аж прошлым летом.

Zram хромая ось использует с десяток лет по умолчанию и агрессивно

Кто-то наблюдал в действии одновременный zram+zswap? Я ставил одновременно, но поэксперементировать не успел..

Своп в zram aka zramswap, Димез меня на это подсадил, сначала наругал, а потом подсадил.

$ sudo zramctl 
NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd         10,6G 969,7M  238M 261,1M       6 [SWAP]
$ sudo zramswap status
NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd         10,6G 969,7M  238M 261,1M       6 [SWAP]
$ 

Только я до сих пор путаю, zram swap и zswap, просто из за тавтологии.
zramswap это swap в zram, но это не zswap, zswap это zram в swap :)
А кто-то делал zswap c zramswap? Ну типа сжимать страницы и скидывать их в swap на zram? :D

Во! А то спрашивают какую-то ерунду неуместную, типа «есть ли у вас лишние деньги»…

Ну типа сжимать страницы и скидывать их в swap на zram?

Тут уже высказывались претензии к zswap — он, при спуске страниц из своего сжатого буфера в swap предварительно разжимает эти страницы.

Большие серьёзные дяди тоже в состоянии оценить этот «тепловой шум». Им то под это тепло электростанции оплачивать, а так можно закупать на 30% меньше турбин для получения той же самой прибыли...

да ладно !! читай милай читай.
акурат потому и сжимается определенное количество страниц памяти в одну (у zbud 2:1 у z3fold 3:1), чтобы не терять разделение на страницы памяти при отправке на носитель.

Во-первых у меня нет «сред».

В голом айсВМ ничего не поделаешь. Надо всякой фигни напихать, управлялку звуком там, или сетью, или файлменеджер. Оглянуться не успеешь, и вот уже всяких хреновин наберётся больше чем процессов было в винХР. Оно всё ещё будет лёгким и быстрым, но уже не «просто айсВМ».

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

rrr@raspberrypi:/tmp $ df -m | grep tmpfs && uptime
devtmpfs                    1640            0     1640            0% /dev
tmpfs                       1898          102     1796            6% /dev/shm
tmpfs                        759            1      758            1% /run
tmpfs                          5            1        5            1% /run/lock
tmpfs                      25600          712    24889            3% /tmp
tmpfs                        380            1      380            1% /run/user/1000
 14:43:12 up 24 days, 15:34,  4 users,  load average: 0,33, 0,78, 0,77

Вроде всего то 712М (это без альбома, открытого в audacity), но уже 18% от оперативки.

А можно ещё вариант ответа «Что это за эбола».

Нигде не использую. Но хочу обратиться к знатокам, в рамках серверного использования данные ухищрения могут ли дать какой-то плюс и в чем?

Я же правильно понимаю - если памяти достаточно, то это всё не нужно и свап лучше просто отключить?

Или будет всё равно умничать и может выгрузить страницу с кодом в mapped исполнимый файл на диске, и потом словит page-fault?

шо сервер, шо десктоп, если памяти хватает (засирание кешами и буферами исключаем) то смысла в подобных приблудах нет.

в рамках серверного использования

Суть идеи в том, что на десктопе проц простаивает 90% времени, а память хром жрёт как не в себя. Поэтому можно незаметно для пользователя заниматься сжатием. На сервере нагрузка как правило равномерная, т.о. этот номер не пройдёт (в лучшем случае шило на мыло).

Надо всякой фигни напихать, управлялку звуком там, или сетью, или файлменеджер.

Всё равно это намного меньше чем «среды». К тому же одновременно большинство из этого не запущено. Ибо зачем мне управлялка звуком если я схему в KiCAD рисую,а не дискотеку дома устраиваю. А когда будет дискотека мне не нужен файловый менеджер. Ну и так далее.

up 24 days

Я обычно не держу домашний комп включенным месяц подряд. Незачем ему работать если я сплю или хозяйственными делами занят.

а память хром жрёт как не в себя.

У меня хотя и не хром,а vivaldi,но оно тоже на движке хрома. Можно пожалуйста ссылку куда надо зайти чтобы оно выжрало память так что система свопиться начала? Хотябы на маленьком компе (моноблок Asus) где четыре гига памяти.

несколько страничек с тяжолым джаваскриптом :) ты труб и подобные. хотя сейчас каждая страничка обсижена джаваскриптами как мухами.

Всё это должно оказаться в однокликовом доступе сразу же как только понадобится. А значит это всё надо запустить заранее... Короче мы получаем окружение! Ну как 20 ключей и плоскогубцы в одном мешке автоматически превращаются в набор инструмента.

А смысл его выключать, если он потребляет в 4 раза меньше циркуляционного насоса отопления (котёл и клапан отсечения газа - отдельно) и даже меньше охранной сигнализации? 1,15 р/сутки на холостом ходу если точнее.

Даже если памяти достаточно, лучше включить на какой нибудь аварийный случай. Разве что в конфигурации попроще - либо простой своп без сжатия памяти, либо zram без физического свопа.

В своё время всякие гентушники и построители билд-ферм наглядно показали, что комбинация сборки в tmpfs + довольно агресивное сжатие памяти даёт выигрыш во времени когда памяти с избытком и очень сильно снижает потерю времени если памяти в недостатке.

Скорее всего это будет верно для любой нагрузки со сжимаемыми данными или софтом с нестабильным потреблением оператики.

не использую, но нужные технологии, просто я лентяй.

если своп просто отключишь, то когда запустишь андроид-студио аки идею, то она упадет, когда ява сожрет всю память. с zram’ом ты сохранишься и перезапустишь ее

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

да ты чё, в корне не верно. если у тебя система жрет память, то вместо «упрешься в окончание рам» будет «упрешься в окончание свопа» тока чутка попозже :)
заряженный пистолет аккурат в пожирании памяти а не в ее количестве и виде.

а как верно, гуру, просвяти?