Comments 70
Как данный подход дружит с дисковым кэшем сейчас? На значительно более ранней версии Ubuntu я наблюдал сильную деградацию скорости подгрузки исходных кодов при фактическом увеличении объема памяти.
Не проще ли — вместо того, чтобы заниматься настройкой тормозящих систему костылей — взять более экономный по потреблению ресурсов дистрибутив Linux с более экономным оконным менеджером? Ставить развесистый Ubuntu при нехватке RAM — мягко говоря, странное решение.
Некоторое время назад была статья с анализом кода такой популярной тогда утилиты SoftRAM, версия для Windows 95 содержала только заглушку для реализации сжатия, в реальности реализуя во всех выпущенных версий только метод COPY (без сжатия). :)
вводим команду
Get-MMAgent
проверяем вывод консоли. В части выводимых данных в строке MemoryCompression вы увидите либо False (Не Включено) либо True (Включено):
Как включить или выключить сжатие в Windows 10/11?
Сжатие включается из той же консоли Powershell командой
Enable-MMAgent -mc
Результаты включения сжатия проявят себя при определённых обстоятельствах, то есть при серьёзной нагрузке на систему.
Выключаем так:
Disable-MMAgent -mc
Обе операции подразумевают перезагрузку Windows.
я еще помню времена, когда mmap был в Linux, а в Windows не было (если не ошибаюсь, давно было).
а как лучше поступить для игр, выключить или оставить включенной?
по умолчанию была включена.
выключить можно если у вас 64gb
но тогда она и сжимать не будет.
она сжимает вместо! того чтобы кинуть в свап.
у меня 16 ОЗУ, и 4-8ГБ свопа
ок, оставляем включенным) спасибо
Спасибо
Охереть. А что жрет 64 гигабайта? У меня 32, больше 700 открытых вкладок в хроме и пара свернутых игр, но память не заполняется.
Помнится, для Win-98SE было несколько «оптимизаторов», якобы сжимающих содержимое RAM. Но и оперативной памяти в системнике тех времён было на два порядка меньше.И некоторые из них (к примеру MagnaRAM из QEMM), вполне себе работали и до появления Win98se, и в 3.1(1) и 95. ''МЯГКАЯ'' ПАМЯТЬ. ПО для увеличения объема ОЗУ
Даже с неразвесистым дебианом, где поставлен lxde, лучше добавить пару гиг через zramswap, ибо браузер сожрёт всё.
Такая же по смыслу технология в MacOS и Windows текущих используется. Но есть вопрос все-таки, почему в Ubuntu ее не включают в дистрибутив, если она такая классная.
Я так понимаю, логика в использовании сжатой оперативки есть, когда она промежуточная между используемыми данными и данными в swap. А когда вместо swap - спорно. Система хочет скинуть в своп данные, которые ей скорее всего пока не понадобятся, а тут раз и свопа нет, и ей все равно приходится хранить эти данные пусть и сжатые, но в той же оперативке, которой не хватает.
Только:
а) бинари, в общем случае, сжимаются гораздо лучше мультимедии, потому что мультимедия и так сжата по умолчанию, а бинари — нет
б) сжатие прекрасно работает на регулярных паттернах, в кои входят и декомпрессированные текстуры, и другие структуры в памяти
в) сжатие памяти это трейдофф, и его надо применять там, где он подходит. Обычно лучше увеличить количество памяти и/или свопа
Уровень сжатия бинарей — меньше 1%
Вы путаете бинари и энтропию. Высокоэнтропийные данные не сжимаются или сжимаются очень плохо, это да.
Бинарь, состоящий из хорошо сжимаемого паттерна — нулей, например — все еще бинарь. С коэффициентом сжатия хоть 1:1000000000, если длина и паттерн позволяют.
Какой смысл говорить о бинарях, которые никогда не попадутся пользователю?
Сжатием памяти занимается не пользователь, ВНЕЗАПНО.
И представление в памяти, ВНЕЗАПНО, частенько низкоэнтропийное.
Практически все бинари — это высокоэнтропийные данные
Структуры БД, например, которые ведет в том или ином виде практически любое приложение. Текстуры, карты и битмапы. Объекты, списки и другие структуры используемые приложением в памяти, которую можно сжать.
Продолжать можно бесконечно.
Накидал рандомных бинарей в winrar:
PE/ELF на диске и рантайм память приложения все-таки две большие разницы...
-rw-rw-r-- 1 user user 14137013952 Oct 18 08:49 core.1821058
-rw-rw-r-- 1 user user 217008622 Oct 18 08:49 core.1821058.zst
Что даёт размер сжатых данных на уровне 1.54% от исходных.
Уровень сжатия бинарей — меньше 1%Вот прямо ща взял:
regedit.exe 361 Кб
regedit.7z 122 Кб
Wow.exe 7,34 Мб
Wow.7z 2,42 Мб
JoplinPortable.exe 189,8 Мб
JoplinPortable.7z 183,6 МбВезде больше 1%.
В графике таких паттернов до 40% от объема, в мультимедиа они периодически бывают, например повторяющиеся фреймы.Покажите работающий на уровне ФС способ сжатия (кроме мультимедиа энкодеров), способный сжать хотя бы i-frame only видео (после intra-frame энкодера).
кринж
Нет смысла ставить linux на сверхмощный комп с прекрасным процессором - игрушки играют на виндовых машинах (оставим тот процент, который играет на wine)
пффф... 24 ядра, 64гб оперативы, gtx 1080, на компе стоит линукс, если хочу поиграть в игры, включаю стим, выбираю желанную, нажимаю зелёную кнопку "запустить", играю.
wine отдельно не ставил, не настраивал, не костылил ничего, вместе со стимом давно идет Proton, родственник вайна, заточеный чисто под игори. Ставится сам, ничего от тебя не просит, на данный момент у меня вся библиотека, 300+ тайтлов, помечены как поддерживаемые.
Просто покупаешь игру, ставишь, запускаешь.
Протону много лет, но раньше поддержка была очень урезанная. Но после выхода Доски Габена, она же SteamDeck, ситуация пошла в гору огого как.
То, что гейминг не про линукс, уже давно устаревший стереотип.
Технология рабочая!!! :)
https://store.steampowered.com/app/501500/Black_Moon_Chronicles/
Работала минут 20 без "quarterdeck magnaram" - лютая утечка памяти, с компрессией можно было закончить уровень.
Звуковая дорожка - шедевральная
zram имеет смысл использовать когда swap недоступен, а память нужна. В противном случае целесообразнее использовать zswap (тот же zram, но ещё и умеющий реально сбрасывать сжатые данные на диск при недостатке памяти).
Жалко что на диск данные из zswap по какой-то причине сбрасываются не сжатыми.
Потому что pda0 ошибся, это стандартный механизм, и он ничего не знает о сжатии страниц.
Но, в целом, если есть шансы, что данные в свап сбрасываются не большими кусами, а страничка тут, страничка там (а это поведение ожидаемое) — то zram будет скорее вреден.
Зато он хорошо заходит на смартфонах, где писать на флэш не желательно.
Ну, справедливости ради, у смарта больше шансов быть выброшенным по причине "уже много лет не поддерживается производителем", чем дождаться смерти встроенной flash-памяти.
Не жаль абсолютно, это имеет под собой совершенно конкретный здравый смысл.
А в Fedora это из "коробки"...
хабр, который мы заслужили
zram клевая штука — юзаю ее на апельсинках.
Но при каком количестве памяти это оправдано?
Да и лишаться возможности уходить в сон не хотелось бы.
ошибка в памяти может стать более разрушительной на сжатых данных. Зато и более заметной.
Использовал такое на "сервере" с 512 оперативки. Позволило поднять эффективный размер памяти в среднем более чем в два раза. Свап не отключал, а расставил приоритеты - zramовский своп сначала, обычный - потом. при этом zram своп сделал гиг (х2 от ОП).
Просто включения службы zram в линукс дистрибутивах обычно недостаточно, необходимо хотя бы минимально "подтюнить" ядро при помощи sysctl.
Я обычно меняю параметры vm.swappiness = 170 (увеличение использования swap, в старых ядрах максимум можно было выставить 100) и vm.page-cluster = 0 (уменьшение страницы памяти для более активного копирования в zram).
Hidden text
Толку от zram много не будет. Проще купить самсунговский быстрый SSD со своим большим RAM (кеш-памятью) и вставить вместо штатного. И да, на нём сделать swap. Который будет работать во-первых со скоростями сопоставимыми с zram, во-вторых способен принять значительные объёмы.
Для примера, имеем такую картину в момент перехода в браузере по нескольким десяткам вкладок, см. ниже, из свопа читается или выкидывается порядка 20 МБ/сек, что намного ниже пиковой производительности SSD.
```
$ free
total used free shared buff/cache available
Mem: 8058404 6677464 748932 238356 632008 891148
Swap: 31250428 2107904 29142524
$ vmstat -n 1
(как вставить в хабр преформатированный текст я не понял, видимо никак).
На "почти бесплатных vds" с урезанной рамой и ограничением по иопсам толк есть
Проще купить самсунговский быстрый SSD
время доступа (а именно оно важно для своппинга) на разным ssd не так уж сильно отличается, если говорить про чтение, то от ≈100 мс на sata до ≈50 мс на топовых nvme.
и samsung тут ничем не выделяется.
со своим большим RAM (кеш-памятью)
так не бывает.
ram обычно ставится из расчёта один гигабайт на тербайт ёмкости (если не брать dram-less ssd) и используется память в первую очередь для хранения таблицы ftl.
Что??? 1.7мс вот конкретно на Samsung SSD 860 EVO.
ioping -c 100 -i 0.1 -s 65536 /tmp/
...
--- /tmp/ (ext4 /dev/sda6) ioping statistics ---
99 requests completed in 157.1 ms, 6.19 MiB read, 630 iops, 39.4 MiB/s
generated 100 requests in 9.90 s, 6.25 MiB, 10 iops, 646.3 KiB/s
min/avg/max/mdev = 360.9 us / 1.59 ms / 1.70 ms / 214.0 us
Какие вообще 100мс, только сейчас сообразил, что во временах 286-х машин было порядка 15мс. На жестком диске!
Бесконечно можно смотреть на огонь, воду, и то, как люди открывают для себя Zram :D
# Specifies amount of zram devices to create.
# By default, zramswap-start will use all available cores.
CORES=4
# Specifies the amount of RAM that should be used for zram
# based on a percentage the total amount of available memory
PERCENTAGE=15
# Specifies a static amount of RAM that should be used for
# the ZRAM devices, this is in MiB
ALLOCATION=1024
# Specifies the priority for the swap devices, see swapon(2)
# for more details.
PRIORITY=100
ALGO=zstd
Взял postgresql сервер на ubuntu 20.04, установил zram-tools, привожу свой конфиг.
Результат, построчно:
PERCENTAGE - количество ОЗУ, которое заберет zram
ALLOCATION - количество в мегабайтах под swap
PRIORITY - приоритет zram в swap
CORES - количество ядер процессора
Результат интересен - по количеству ядер создается несколько swap-файлов в ОЗУ, размер swap = количество доступных мегабайт / на количество ядер:
root@srv-psql:/etc/default# zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram3 lzo-rle 298,4M 4K 73B 12K 8 [SWAP]
/dev/zram2 lzo-rle 298,4M 4K 73B 12K 8 [SWAP]
/dev/zram1 lzo-rle 298,4M 4K 73B 12K 8 [SWAP]
/dev/zram0 lzo-rle 298,4M 4K 73B 12K 8 [SWAP]
Так самое интересное: что с постгресом в итоге? )
У меня скорость чтения m2 2666 и ОЗУ 2666. Своп создан исключительно для снижения загрузки диска и сжатия данных. Тест Гилева показывает стабильно одинаковый результат . На запись SSD 1700
честно скажу, ничего не понял из вашего ответа.
Тест Гилева показывает стабильно одинаковый результат
читать как «от включения zram результатыт теста гилёва не изменились»?
Своп создан исключительно для снижения загрузки диска и сжатия данных
что вы сейчас имеете в виду под свопом? обычный swap-раздел? zswap? zram?
У меня скорость чтения m2 2666 и ОЗУ 2666
2666 чего и 2666 чего? кажется, что у вас единицы измерения не совпадают.
и для свопа задержки важнее пропускной способности (а задержки dram и ssd отличваются порядка так на три).
и причём тут вообще m.2, если мы в обсуждении zram?
Вы задали вопрос о postgres, так как я привел пример postgres на ubuntu 20.04, в котором развернул zram, в части рассмотренного в стате zswap-tools.
В собранной конфигурации компа установлена ОЗУ ddr4 4*16gb, частотой 2667, тайминги смотреть лень. Также в порт m2 той же материнки установлен SSD 1tb со скоростью записи 2666 и чтения 1700. Остальные характеристики железа нас не интересуют
Цель проверки: оценка работы zswap в размере 1024мб, который приоритетом 100% перед swap os Ubuntu 20.04 будет предоставлять сжатие в ОЗУ, а если ему не будет хватать под swap 1024 гб zswap ОЗУ, то уже использовать swap диска ssd,.
За счет сжатия свопа postgres ожидалось, что производительность изменится
Она не изменилась
Но создал предобработку из zram до сброса swap на ssd в надежде, что писать кэш данных на диск будет реже, а чаще в ОЗУ zswap, созданный по данной статье, с помощью установки zram
Надеюсь, разжевал все.
ну я бы начал с оценки того используется swap в оцениваемом сценарии (iostat -mxzp 10, например, покажет сколько iops на каком разделе сейчас есть).
подозреваю, что нет )
Также в порт m2 той же материнки установлен SSD 1tb со скоростью записи 2666 и чтения 1700. Остальные характеристики железа нас не интересуют
я уже написал выше, для целей свопа эти характеристики нас тоже не интересуют, интересует время доступа (впрочем, для приличного nvme я могу предположить, грубо 50 мкс на чтение и 15 мкс на запись).
А если рам нужен под WSL, то включать сжатие на Линуксе или на винде? Подскажите пожалуйста.
Linux: «Бесплатная» RAM за счет процессора