Минусы выставления большого zram и маленького swappiness?

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

А что тогда за мантра про 50% оперативки, и про swappiness не часто упоминают? Окей, обращение к zram несколько медленнее, поэтому настроим так чтоб сжимал данные в крайнем случае. По дефолту используется «быстрый» режим благодаря swappiness, а как приспичит, пусть сжимает хоть всю оперативку, всё равно лучше чем своп-файл будет.

Недостатки?

Ты неправильно трактуешь принцип работы swap-а.
Понятно, что в данном случае ты хочешь «расширить» RAM.
swap держит копии страниц из RAM, чтобы в любой ситуации можно было мгновенно избавиться от данных в RAM (освободить место для чего-то более нужного, поэтому все дисковые свопы по размеру меньше размера RAM по сути задрачивание диска) - т.е. память в правильный своп выгружается в фоне, когда ты не замечаешь, а «уход в своп» - это внештатная ситуация, когда надо освободить те страницы RAM, которые ещё не выгружены в своп.
Возможно, если у тебя нет на машине проблем с диском, имеет смысл сделать 50% и максимальную swappiness - тогда у тебя на диске будут лежать сжатые страницы памяти из zram... Но это не точно.

система выгружает в swap файл когда меньше 10% оперативки остаётся

Нет.

Во-первых, твоя идея о назначении vm.swappiness даже рядом не стояла с реальным ее назначением.

Во-вторых, swap и mmap это родные сестры page cache. Снижая сваппинес ты заставляешь систему активней дропать чистый кэш (то есть по сути скатываешь систему в трэшинг).

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

Вообще не подтверждаю. В рецептах «розгона линукс» часто упоминается маленький сваппинес, и 10 и 1 и тд, с оговоркой что памяти куча.

Гугл пишет, что возможно снижение производительности, что вряд ли очень актуально на ssd

Reduced File Cache: The kernel uses free memory to cache file-backed data. By forcing the system to keep inactive processes in RAM (because you lowered swappiness), less memory is available for caching, which can result in slower disk I/O performance.

Если это не однопалатник с sd картой - просто используй zswap.

forcing the system to keep inactive processes in RAM

Зачем это тебе?

По Гуглу доступ к ram сильно быстрее.

Оперативная память (RAM) работает в 10–100 раз быстрее, чем современные SSD-накопители, по скорости передачи данных (линейная скорость), и в тысячи раз быстрее по времени отклика (задержке)

Вообще не подтверждаю

https://habr.com/ru/articles/541214/

При нехватки чистой оперативки система и так будет выгружать неактивное. А если хватает, то и смысл выгружать.

Сейчас не за ноутом, но насколько помню, в process monitor отображалось нечто вроде 1.5-2.3 Гб кэшировано при swappiness 10. Не думаю что это прям мало.

Тем более чтоб система прям в «тренинг» превратилась.

Вчера поймал некоторое подтормаживание (не факт что из-за нехватки оперативки), но у меня 93% оперативки было использовано, и больше половины zram. Файрфокс опух, после закрытия вкладок прекратилось.

При нехватки чистой оперативки система и так будет выгружать неактивное. А если хватает, то и смысл выгружать.

- вот это и есть неправильная логика. Выгружать надо, пока хватает. Когда не хватает, поздно свопом пользоваться.

И статья не подтверждает. И сама программа аж 14 Гб оперативки запрашивает, код специфический, swappiness 0 вообще отключает, 1 в 10 раз меньше чем 10. Сброс данных в режиме исчерпывания оперативки в swap ≠ zram.

Это всё правда, но zswap тоже сжимает страницы вместо отправки их на диск, пока может себе это позволить, а также делает это гораздо умнее, чем zram. На современных ядрах zram имеет смысл только вместо swap на каком-либо носителе.

zram не тоже самое, что и файл подкачки на винчестере или ssd ~_~

Когда программе нужно 1 Гб, а свободной 10 мбайт и начнется обращение к жёсткому диску или ssd это одно, можно и повиснуть. Обращение к zram тоже обращение к оперативке

swappiness надо выставлять не по оперативка/zswap/swap, а по нагрузкам и характеристикам диска. Часто запускаешь программы, а ssd не очень быстрый? Лучше за сотню. Хард? Не помню, новроде бы лучше маленькое значение. ssd быстрый в любых сценариях? Скорее всего даже тесты не смогут выявить разницу.

По дефолтам zram 50% оперативки.

Нужно уточнение: размер сжатого рам-диска 50% от оперативки, или 50% от оперативки в предполагаемом сжатом виде? В первом случае весьма скромно. Во втором подумать надо, может и многовато, а может и нет.

Кто не в курсе...

Поправка: не сжатого файла подкачки, а сжатогоблочного устройства подкачки. Хочешь просто сжать своп - задействуй zswap. Это почти то же самое, но без блочного устройства. Есть и другие нюансы, благодаря которым zswap чуть быстрее поднимает даные из свопа а zram чуть быстрее их туда сбрасывает.

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

Недостатки?

Почти никаких. Очень трудно найти настолько слабое сочетание процессора и объёма и скорости памяти на которых сжатие свопа будет чувствоваться. Кстати, современные ssd почти всегда достаточно быстрые (даже sata->usb3) чтобы сжатие свопа не давало видимых на глаз преимуществ в скорости. Но вот ресурс записи заметно экономит и всё таки сказывается в жёстком недостатке памяти, более 160-200% от физического объёма оперативки. Короче не волнуйся, когда ОС решила свопиться это всегда значит что у процессора появилось лишнее время.

С другой стороны у меня такое сочетание как раз есть. Распбери Пи 4 4Гб, достаточно ёмкий чтобы тянуть браузер без свопинга (иногда, 50/50), но недостаточно быстрый однопоток и чудовищно медленная ОЗУ, так что процесс сортировки страниц между свопом и з-свопом немного тормозит. Снизил размер пула до 25% и тормоза ушли.

Если одноплатник с sd картой - тоже можно.

огда программе нужно 1 Гб, а свободной 10 мбайт и начнется обращение к жёсткому диску или ssd

Нет, в этот момент на диск почти ничего не записывается, а просто освобождается RAM. Потому что УЖЕ записано.

zswap точно, гарантированно лучше zram в любом случае, если есть возможность сделать swap на блочном устройстве.

Так, давай с базового уровня. Вот есть память приложений, память ядра, разделяемая память (которая используется сразу несколькими приложениями или драйверами в ядре), разные буферы и кеши. И то что свободно, её не следует занимать на 100% потому что механизмы «не хватает памяти, надо освободить» и «дай мне 100Мб» это совершено разные механизмы и выделение может рухнуть вместе с программой если нет запаса куда выделять.

swappines, mglur и всякие прочие планировщики и их настройки не указывают напрямую что вот столько надо держать в резерве (больше нет, хотя раньше да), но всё это как то влияет на решение что именно вытеснять в первую очередь, что во вторую, когда начинать и как активно действовать. Это ещё до того, как процесс упрётся в скорость процессора или диска.

Маленький swappines заставит отбрасывать кеши и максимально держать в памяти приложения, а большой наоборот, сбрасывать приложения но держать в памяти большой кусок кешей. Сейчас выбор совсем не очевиден! Приложения написаны так, что в них дофига мёртвого кода, часто можно сбросить в своп 50-70% и это никак не скажется на реальном функционале и скорости приложения. С другой стороны то что вроде бы ненужный кеш может оказаться кодом библиотеки или базы данных, к которой надо обращаться тысячи раз в секунду. В итоге средние значения swappines от 50 до 150 при быстром ssd работают примерно одинаково, а разницу надо искать в структуре чтения и записи на диск. Классикой считается 100 или 150, ходят упорные слухи что это лучше чем 60.

Дальше, когда принято решение вытеснить страницы - встаёт вопрос куда именно. Если активирован zswap - сначала туда. Страница будет сжата и помещена в zpool. Если страница не сжимаемая или пул переполнен - она разжимается и отправляется в своп.

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

И вот тут появляется zswap - он может быть одним из этих устройств. Всё что в него отправлено будет сжато и как положили так и будет лежать (за исключением backing_dev, но это позже). Сначала до отказа забивается zswap и продолжает висеть в оперативке, заняв там некий кусок (как получится, возможно даже 100% от разжатого объёма). Всё что сверху будет отправлено в менее приорететное устройство (физический диск очевидно) без сжатия. В сценарии когда ты открываешь вкладки в браузере бесконечно большими пачками - после заполнения zswap тебе придётся жить без него в оставшейся оперативке пока ты не вернёшься к самым первым вкладкам.

И вот чтобы этого избежать, придумали backing_dev. По сути свой собственный своп для zswap. Работает как своп, только исключительно для содержимого zswap. Позволяет включить себе бесконечно большой zswap, хоть в 1000 раз превышающий оперативку и он не переполнит ОЗУ. Можно указать какой именно объём zswap будет физически занимать в оперативке.

Очевидно одновременное включение zswap и zram - тупая идея. Надо выбрать, или тот или другой с backing_dev. Или без backing_dev, но это предварительно подумав почему именно тебе именно в этом сценарии ужно так сделать. zswap с околодефолтными настройками даст тебе 90% всех возможных плюшек. Нормально настроенный zram+backing_dev даст 100%. Но если так подумать, то за счёт голой производительности современных ssd и быстрых шин ты получаешь 50-70% от этого вообще не используя сжатие свопа. Вот на hdd или usb2-ssd свопинг действительно превращается в тормоза...

Недостатки

лажа полная - zswap гораздо лучше

У меня 8 гб, решил попробовать выставить 90% зрам

И оно всё повесится как только в zram упадёт достаточно данных.
Как минимум из-за того, что данные не обязаны всегда сжиматься в 2-3 раза.

О, вот и кексперты подтянулись.

В чем-то тут сферические кони в вакууме описаны. Не обязательно использовать так чтобы весилось. В статье выше про zram начнется с того какой он хороший, когда оперативка исчерпана. Можно делать сравнение эффективности железок при игре в cs2 на ультрах в бане.

И про zswap не понятно, или речь о том что «у меня 50 Гб оперативки, в основном играю в шахматы, включил zswap и все летает» или прям активно использует zswap, или на крайний случай.

Android всякий, ТВ приставки живут без прекрасных swap или zswap, хотелось бы не использовать своп на диске вообще, если это не сильно ухудшит результат.

Никак тебе возня ни с ZRAM, ни со сваппинесом не поможет.
Важно чтобы ядро не выгружало библиотеки и образы необходимые для обеспечения отзывчивости интерфейса.
Хоть в три погибели сожми всё в оперативке — когда графическая либа будет выгружена на диск у тебя система фактически встанет колом (вплоть до того, что SysRq не будет работать).

Андроиды как раз делают свои реализации cgroup/mglru/prelockd, чтобы важные образы из ОЗУ вообще никогда ни при каких обстоятельствах не вытеснялись (ну и чтобы на них оставалось процессорное время, но даже без контроля процессорного времени, только на сохранении образов в памяти достигается отличный результат).

Куда что выгрузится, если на диске нет файла подкачки. На ссд тоже колом встанет? Если выгрузится в своп на zram, встанет? У меня только лёгкое подтормаживание было при заполнении оперативки на 93%, и то не факт что не процессор был загружен. Закрыл лишние вкладки в браузере и норм

Куда что выгрузится, если на диске нет файла подкачки.

Тогда никуда.

На ссд тоже колом встанет?

Будет медленно и ресурс ССД сократится.

Если выгрузится в своп на zram, встанет?

Не думаю.

У меня только лёгкое подтормаживание было при заполнении оперативки на 93%

На 100% посмотри.

Будет медленно и ресурс ССД сократится.

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

На 100% посмотри.

Но зачем? Такие сценарии не особо предусмотрены, и даже если подлагивание начнётся, можно в браузере (не)много вкладок закрыть. Вот когда когда-то был своп на жоском диске, что-то предпринять было прям проблематично.

Вот скрин с сваппинесс 10

https://ibb.co/PsqndgNv

Кэшировано 2.4 Гб, свап 7%. Вряд ли система загибается от недостатка кэша.

Если подробнее

cat /proc/meminfo
MemTotal:        8035664 kB
MemFree:          805836 kB
MemAvailable:    2026304 kB
Buffers:           57740 kB
Cached:          2142340 kB
SwapCached:         4696 kB
Active:          3443904 kB
Inactive:        2716144 kB
Active(anon):    3170852 kB
Inactive(anon):  1461168 kB
Active(file):     273052 kB
Inactive(file):  1254976 kB
Unevictable:      328812 kB
Mlocked:             184 kB
SwapTotal:       7633876 kB
SwapFree:        7103916 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:              9956 kB
Writeback:             0 kB
AnonPages:       4284584 kB
Mapped:           510912 kB
Shmem:            672052 kB
KReclaimable:     128896 kB
Slab:             280100 kB
SReclaimable:     128896 kB
SUnreclaim:       151204 kB
KernelStack:       21568 kB
PageTables:        73292 kB
SecPageTables:      2584 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    11651708 kB
Committed_AS:   12795204 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      104596 kB
VmallocChunk:          0 kB
Percpu:             3328 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:     55296 kB
FilePmdMapped:     53248 kB
CmaTotal:              0 kB
CmaFree:               0 kB
Unaccepted:            0 kB
Balloon:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      189752 kB
DirectMap2M:     4958208 kB
DirectMap1G:     3145728 kB

Да и вообще вопрос больше был про большой zram чем про swappiness, хотя для интереса могу и 100 попробовать.

мантра про 50% оперативки

Zram по дефолту оперативку использует. Так максимум 50 процентов сожрет, а не всю. То есть сжимается и кладется в оперативку.

Несколько вопросов.

1. А какой средний процент сжатия страницы в zswap? Понятно, что вот так наобум сказать нельзя, но хотя бы порядок. Что лучше сжимается, код, данные, или буфферы I/O? Можно ли указать, какие страницы отправлять в zswap, а какие нет?

2. Отправляются ли zswap страницы в swap? Какой алгоритм выбора страницы, которая отправляется в swap при наличии zswap?

zram рекомендуют применять (и применяют в андройдах) вообще без своп-файла. Если он займёт максимум 50% оперативки, при заполнении её встанет колом (хотя андроид нормально неактивные приложения завершает). При ~100 процентах оперативки (пусть 90) останется свобода действия.

И если что-то памятеёмкое запускать, прокатит, а с 50% могёт зависнуть.

кексперты

у меня кЕк всегда - на своей шкуре проверено, изначально пользовался swap и когда свопилось - нещадно тупило, потом попробовал zswap это гораздо лучше, когда свопится на глаз конечно видно, но не вызывает желания зарубить монитор топором, а с zram просто все встанет колом когда память закончится и свопится даже очень медленно никогда не начнет, хорошо если памяти 64 гига и более, а если буквально пару гигов - zram не поможет.

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

выставить 90% зрам и swappiness в 10. Что по идее значит, что система выгружает в swap файл когда меньше 10% оперативки остаётся, по дефолту будет использоваться оперативка.

Нет, swappiness=10 значит, что у вымещения файлового кеша очень высокий приоритет.

Swappiness настраивается от 0 до 200. 100 это нет приоритета между вымещением кеша и сбрасыванием страниц в swap, а 200 — стараться сбрасывать страницы и не вымещать кэш, насколько это возможно.

Я рекомендую ставить не меньше 100. Если процессор быстрый, вы получите больше отзывчивости десктопа от файлового кеша в памяти, чем от сброса страниц процессов.

https://valdikss.org.ru/linux.txt

Только зачем-то постоянно транслируешь свое мнение в безапелляционной манере… Ты же понимаешь, что твой опыт с «дореволюционным» железом — он, как бы сказать, не совсем обычен? Да и условия и задачи могут быть разные? Можешь грамотно аргументировать свой коммент ненужно (именно так он читается, я бы на месте модераторов снес)? А так получается пришел, какаху кинул и был таков. Зачем? Тут вроде как технический форум.

ЗЫ Если система «колом встает», то дело тут вовсе не в zram и ни в zswap, надеюсь «почему» объяснять не надо.

Я рекомендую ставить не меньше 100. Если процессор быстрый, вы получите больше отзывчивости десктопа от файлового кеша в памяти, чем от сброса страниц процессов.

Файловый кэш какого именно рода? Браузеры быстрее работать будут, или подрузмевается что я по 10 программ в минуту запускаю и бесконечно закрываю? Насколько на ssd актуально?

Сколько должен весить оптимальный файловый кэш? У меня кэш даже с сваппинесс 10 2.4 Гб из 8 занимает.

с 8 гигами продержаться могу

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

Хотел написать свою историю, но передумал, напишу итоги.

При 8 Гб RAM игра Oxygen not included: Spaced Out не запускается, при zswap 4 Гб zswap.max_pool_percent=50 - не запускается, при zram 4Гб - запускается.

Сейчас у меня zram установлен на 12 Гб, vm.swappiness = 160 zram начинает использоваться после 6 Гб потребления памяти, сжатие ниже 3 почти никогда не видел, начинает гудеть вентилятор и появляются лёгкие подтормаживания. Пооткрывал сейчас кучу всего, суммарно используется 14 Гб памяти, особых тормозов не заметно.

> $ free -h
               total        used        free      shared  buff/cache   available
Mem:           7,6Gi       6,0Gi       630Mi       1,2Gi       2,4Gi       1,6Gi
Swap:           13Gi       9,5Gi       4,4Gi
> $ zramctl --output-all
NAME       DISKSIZE  DATA COMPR ALGORITHM STREAMS ZERO-PAGES TOTAL MEM-LIMIT MEM-USED MIGRATED COMP-RATIO MOUNTPOINT
/dev/zram0      12G  8,9G  1,8G zstd                  148182  1,8G        0B     1,8G   124,5K     4,8248 [SWAP]

Только алгоритмы сжатия бывают разные, да и зрам больше размера оперативки быть заполнен не может. Размер зрам - размер после сжатия

Ты же понимаешь

а вот ты гляжу неочень… сейчас объясню на примере mitigations=off, неоднократно прописывал это в различных ситуация, но никакого прироста не ощутил, пока не прописал это в мегасупердореволюционный 4-ый пень и вот тут я сразу почувствовал разницу, а помогло мне в этом слабость и убогость железа которое работает фактически на грани своих возможностей и даже незначительные приросты тут же заметны, теперь вернемся к памяти - если ее дофигища то можно зазрамиться хоть доусрачки, если не видишь проблем - значит ты просто всю память не пожрал и что бы ускорить процесс понимания - надо избавиться от лишнего объема и оставить 2 или вообще 1 гиг, вот тут zram покажет себя во всей своей красе - выжрет память и все встанет колом

грамотно аргументировать свой коммент ненужно

если памяти много то ненужно потому что памяти и так дофига, а если памяти мало то ненужно потому что вредно

хорошо если памяти 64 гига и более,

что 64 что 8 - разницы никакой, тут можно не париться - памяти так хватит без всяких свапов, зсвапов и зрамов.

Лол. Памяти не всегда хватает, но причина банальная, браузеры кучу хавают и автоматом не приостанавливают. Да и так можно то се на открывать. Можно и доп плашку воткнуть, но это покупать, разбирать. Зрам быстро ставится

а вот ты гляжу неочень… сейчас объясню на примере mitigations=off

Во первых: я ничего не утверждал. А во вторых: приди в себя, ты бредишь.

если памяти много то ненужно потому что памяти и так дофига, а если памяти мало то ненужно потому что вредно

Аргументация агонь! Пиши еще.

что 64 что 8 - разницы никакой, тут можно не париться - памяти так хватит без всяких свапов, зсвапов и зрамов

лол-кек

Нет, размер zram disksize это сколько туда будет записано. Место в памяти выделяется по факту потребления. Опционально может быть ограничено через mem_limit.

Сколько должен весить оптимальный файловый кэш? У меня кэш даже с сваппинесс 10 2.4 Гб из 8 занимает.

Мимокрокодил:

$ free -m
               total        used        free      shared  buff/cache   available
Mem:            7690        2265         532         282        5797        5425
Swap:          12287         140       12147

zRam

vm.swappiness = 180
vm.watermark_boost_factor = 0
vm.watermark_scale_factor = 125
vm.page-cluster = 0

Памяти не всегда хватает

смотри как это работает: памяти 2 гига - система свопится и тупит потому что памяти мало, в таких случаях использовать zram бесполезно… памяти 8-64 гига - системе не свопится и не тупит потому что памяти дофигища, полно свободной - вот тут можно использовать zram только зачем?

браузеры кучу хавают

смотря какие и смотря сколько вкладок открыл

Аргументация агонь!

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

лол-кек

было у меня 2 гига - свопилось и раздражало, при попытке использовать зрам - все колом вставало, не сразу - за то резко, установил 4 гига и свопиться перестало, можно конечно теперь и зрамом обмазаться - только смысла не вижу.

Есть АТВ приставки, на 1,2,4 Гб. Не сказать что особо что-то тупит даже на 1. Но работает медленнее. Процессоры сильно разные.

Вкладки не то что сколько открытых держать, я их не сильно закрываю, пока не прижмёт

Твои «офигительные истории» и «я так чувствую» — это не аргументы. А утверждение о ненужности свопа при достаточном количестве рам говорит о том, что ты вообще не понимаешь как это все работает.

С некоторых пор практически каждый андроид использует zram, именно в виде без физического свопа. И в андроид13 вроде как включено на системном уровне а не в виде самодеятельности вендоров. При прочих равных так лучше чем без него. Если по ощущениям - +30-50% операвивки вроде как добавляет, хотя на андроиде ни в чём нелья быть уверенным.

Только на ПК то речь идёт о как минимум вдвое лучших результатах!

Ты сейчас описал правильную настройку swappines ну и всякий прочий тюнинг. Но про «никак не поможет» это ты загнул. Если ты можешь использовать 6Гб оперативки при наличии 4Гб физической до того как первая страница физически упадёт на своп-диск это уже неплохая помощь. Если бы 2,5гб сбрасывались на диск паралельно с перечитыванием библиотек было бы намного-намного хуже.

ты вообще не понимаешь как это все работает

да чего там понимать то? если памяти не хватает - начинает в свап скидывать, в случае со зрам - пережимает и в той же памяти хранит которой не хвататет… решил даже интереса ради псмотреть что там у меня, в машине 4 гига памяти и за 5 с половиной часов аптайма она не засвопилась ни разу - раздел swap девственно чист.