zram и обычный swap нельзя использовать вместе?

скорее всего можно сделать с помощью сервисов, чтобы содержимое оперативы сбрасывалось в файл и добавить resume к kernel parameters

поназагружал в ОЗУ всякого: zram грузится, swap простаивает, - значит норм?

https://gist.github.com/eloylp/b0d64d3c947dbfb23d13864e0c051c67

я за тебя даже нагуглил. там при выключении гибернации swap включается на диске и отключается zram… ну собственно и все. resume прописывается. но мне жалко места под своп. 32 гига оперативы. оно ясно, но я не помню там вроде не вся память записывается, а как-то хитро. для успешной гибернации нужно как минимум вроде файл размером 1/3 от RAM или 1/5

У меня скорее вопрос а зачем эта гибернации нужна, если почти после каждого обновления нужна полная перезагрузка (или как этот boot перевести)

это я так уж, в довесок спросил

Их можно использовать вместе. Просто если хочешь чтобы zram использовался в первую очередь, то ему нужно поднять приоритет.

# swapon --priority 100 /dev/zram0

как просмотреть приоритеты?

swapon их показывает.

$ swapon

swapon без параметров, последний столбец.

аж "-2" ._.

NAME           TYPE      SIZE USED PRIO
/dev/nvme0n1p3 partition 7,8G 104K   -2
/dev/zram0     partition 7,7G 2,6G  100

Но это никак не поможет же

Можно кстати хитрее даже сделать, к zram можно прикрутить backing storage, я сам этого не делал, не очень понимаю как это должно работать и какой эффект даёт.

Но это никак не поможет же

Поможет. Кончится zram и вместо прихода киллера начнёт юзаться обычный своп. Как то так. Если ты про то что в наступивших тормозах всё равно работать не получится — да, не получится. Но ТС спросил как это сделать — ТСу ответили.

он хочет использовать файл ТОЛЬКО ПРИ ГИБЕРНАЦИИ, а в остальных случаях zram

Да эт ладно, главное узнал, что вместе всё ж можно использовать
Хотя у меня ещё и APU, то есть видеопамять из ОЗУ

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

какими-то LRU-инверсиями пугают (я ни чо не понял)

А тебе после исчерпания zram не пофиг ли, киллер пришёл и убил что попало или страшные инверсии и извращения LRU начались, непонятные? И то, и другое плохо. Но по крайней мере второй вариант даёт время самому убить то что протекло.

я в целом не понимаю почему при исчерпании ОЗУ Линукс делает лапки кверху

Ой, тут такая тонкая тема на грани религии, годности умолчальных настроек и демагогии... Что бы я сейчас не сказал прибегут хейтеры, узкие специалисты, адепты «секты ненужности свопа» и т.п., но я скажу. Проблема есть, её долгое время отказывались признавать потому что её можно было сгладить плясками вокруг swapiness и прочих параметров настройки.

Грубо говоря настройки по умолчанию годятся для «среднестатистического» сервера (хотя не очень понятно что такое «среднестатистический», это как среднестатистическая температура больных по больнице, включая гнойное и морг), и не годятся для «среднестатистического» десктопа, который отличается от сервера интерактивностью.

По поводу оптимальных настроек свапа для десктопа есть споры, иногда горячие до «религиозности». Кто то считает что рационально сбрасывать в своп как можно раньше всё что не используется продолжительное время, типа страниц браузера на которые ты минут двадцать уже не переключался, и тем самым освобождать ОЗУ для оперативных интерактивных задач, другие предлагают наоборот, отложить высвапливание до момента острой необходимости, и только тогда высрать всё бурным потоком.

А проблема в том что при любой стратегии сама работа со свопом приводит к «дерготне», что привело к появлению «секты ненужности свапа» как такового. В последнее время ситуация улучшилась, появился zram, zswap, mgLRU...

это ответ про своп, а вот если ОЗУ всё и вместе со свопом или без, то почему Линукс не убивает самый жирный процесс или ещё как-то, а вместо этого дохнет весь почти всегда

Вообще именно так он и должен делать, в теории, должен придти киллер и убить самый жирный процесс. А на практике он плохо с этим справляется, что привело к созданию нескольких альтернативных механизмов ядерных киллеров и к появлению киллеров юзерспейсных. Профессионально в этом разбираются и могут детально объяснить что с киллером «не так» ЛОРовские юзеры hakavlad и post-factum. Я не стал их кастовать в тему с «общим разговором ниочём», спроси их сам, если считаешь нужным, или поищи их темы на LOR.

Современное состояние обработки нехватки памяти в линуксах: MGLRU и le9 патчи и юзерспейсные киллеры например.

Я все проделал как в том гисте, что-то передал и оно работает

$ sudo mount /dev/nvme1n1p1 /mnt/btr_pool 

$ sudo btrfs su cr /mnt/btr_pool/@swap 

$ sudo mkdir /var/lib/swap

$ sudo mount -o subvol=@swap /dev/nvme1n1p1 /var/lib/swap

$ sudo btrfs fi mkswapfile --size 32g --uuid clear /var/lib/swap/swapfile 
create swapfile /var/lib/swap/swapfile size 32.00GiB (34359738368)

$ sudo swapon /var/lib/swap/swapfile                                     

# Добавляем хук resume
$ sudo -e /etc/mkinitcpio.conf
...
HOOKS=(... filesystems resume ...)

$ sudo mkinitcpio -p linux          
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
  ...

$ sudo -e /etc/systemd/system/hibernate-preparation.service                    
[Unit]
Description=Enable swap file and disable zram before hibernate
Before=systemd-hibernate.service

[Service]
User=root
Type=oneshot
ExecStart=/bin/bash -c "/usr/sbin/swapon /var/lib/swap/swapfile && /usr/sbin/swapoff /dev/zram0"

[Install]
WantedBy=systemd-hibernate.service

$ sudo systemctl enable hibernate-preparation                   
Created symlink /etc/systemd/system/systemd-hibernate.service.wants/hibernate-preparation.service → /etc/systemd/system/hibernate-preparation.service.

$ findmnt -no UUID -T /var/lib/swap/swapfile
8ce809ab-7858-4b8e-90cf-7d0f5f220c96

$ sudo btrfs inspect-internal map-swapfile -r /var/lib/swap/swapfile                                     
72754432

$ sudo -e /boot/loader/entries/arch.conf                   
...
options root=PARTUUID=... resume=UUID=8ce809ab-7858-4b8e-90cf-7d0f5f220c96 resume_offset=72754432

$ echo "UUID="$(blkid -o value -s UUID /dev/nvme1n1p1)" /var/lib/swap btrfs defaults,noatime,compress=no,commit=120,nodatacow,subvol=@swap 0 0" | sudo tee -a /etc/fstab
UUID=8ce809ab-7858-4b8e-90cf-7d0f5f220c96 /var/lib/swap btrfs defaults,noatime,compress=no,commit=120,nodatacow,subvol=@swap 0 0

# Опционально
$ echo "/var/lib/swap/swapfile none swap defaults,discard 0 0" | sudo tee -a /etc/fstab
/var/lib/swap/swapfile none swap defaults,discard 0 0

# гибернация не будет запускаться, если размер текущего swap меньше необходимого (у zram по умолчанию максимальный размер 8 GiB)
$ sudo mkdir -p /etc/systemd/system/systemd-logind.service.d

$ cat <<-EOF | sudo tee /etc/systemd/system/systemd-logind.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF

$ sudo mkdir -p /etc/systemd/system/systemd-hibernate.service.d

$ cat <<-EOF | sudo tee /etc/systemd/system/systemd-hibernate.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF

У меня скорее вопрос а зачем эта гибернации нужна

Отправлять в гибернацию по сигналу с УПС после выключения питания.

LRU inversion

При наличии двух своп-разделов - на zram и на диске - обычно выставляют высокий приоритет для zram.

В своп сначала вытесняются самые старые inactive anon pages, и всё - zram выбывает из игры. При этом zram устройство использует часть памяти, но при этом фактически не используется.

zswap лишен недостатка.

Проблема касается zram при совместном использовании свопа на zram и на диске с разными приоритетами. 

zram и zswap или что то ещё,вместе? (комментарий)

Я пробовал swap засрать, он сначала zram заполняет, потом срет на диск

❯ swapon -s
Filename                                Type            Size            Used            Priority
/dev/zram0                              partition       8388604         3020984         100
/var/lib/swap/swapfile                  file            33554428        9208            -2

Ну в этом и проблема.

мне вот чисто академически интересно в таком вот аксепте.
на диск сливаются сжатые страницы zram или как получится ??
имхо первый вариант при современных мощностях проца был бы удобней.

Нет конечно. Второй своп на диске не имеет никакого понятия о zram. И туда льются обычные страницы, не сжатые, после того как zram переполнится. Если есть желание можно поиграть с zram backing storage, я выше ссылку постил. Там можно весьма гибко определять что в этот storage вытеснять, например сливать туда несжимаемые страницы, или настроить «время устаревания» и сливать туда то к чему не было обращений в течении какого то временного интервала.

man zswap

хз, но оно работает

он в арче по умолчанию включен. епта. и причем тут он?

зато я способ нашел посмотреть сколько нужно рамы для гибернации:

~
❯ cat /sys/power/image_size  
13139795968

При том, что он сам по себе обеспечивает комбинацию сжатия и дискового свапа

какое это отношение к теме то имеет?

Меня тут Dimez наругал, попутно предложив zram я губы надул, но внял ::)

Или как-то правильно настраивать надо?

Для эффективности, дабы пожинать все плюшки:

• Отключить swap и zswap вообще.
• Включить zram (тупо установив его)
• Всё.

Как проверить правильность настройки?

Тут всё описано /etc/default/zramswap я выставил

ALGO=zstd
PERCENT=99 # вся оперативка нахер :D

Остальное не трогал. Если оставлять своп обычный то тюнить PRIORITY

Затем sudo zramctl должно показать типа

NAME       ALGORITHM DISKSIZE   DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd         11,6G 650,3M 42,8M 44,4M       6 [SWAP]

Или htop открыть там будет при PERCENT=99 размер zram свопа равный размеру оперативки, если он больше то ты не выключил swap/zswap

Ну и blkid должен показать /dev/zram0: UUID="blabla" TYPE="swap"

Если вместе использовать нельзя, то как использовать спящий режим?

К слову не пробовал… Пока и не буду, оно вроде мне и не надобно.

Там вроде ещё можно сделать чтоб несжимаемые страницы летели в файл/раздел своп, а сжимаемые были в zram, но я не вижу в этом смысла, как минимум для себя. Пусть оперативка жрётся, один фиг в 99% случаев она полупустая.

Надеюсь не бред написал.

P.S.

Distributor ID:	Debian
Description:	Debian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm

Дополнительно, по совету с арвики:

/etc/sysctl.d/99-vm-zram-parameters.conf

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

Это метод, которым я пользовался:

yay -S zram-generator{,-defaults}

# В конфиге можно задать размер иди метод сжатия, отличные от дефолтного
sudo -e /usr/lib/systemd/zram-generator.conf

# Нужно запустить-перезапустить для настройки системы
# zram0 - это название устройства, которое будет создано в /dev
sudo systemctl restart systemd-zram-setup@zram0

Я все перечитал, даже посмотрел статьи вместо вики

https://www.dwarmstrong.org/zram-swap/

И в арче нет аналога zram-tools, который все за тебя делает, а zram-generator, который я использовал вроде как украли у федоры

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

Можно, и что это даст? В чём выгода? zram кончится и машина упадёт. Или киллер придёт. А со вторым свапом начнёт его использовать, и ещё какое то время машина не упадёт. А если zram будет достаточно то до использования свапа на разделе дело и так не дойдёт, так что смысл его выключать\включать в чём?

Как по-мне, это излишне.

Чтобы всё работало без чудес, хватает и пары потоков zram по 500мб.

А вот когда что-то достаточно прожорливое начнет активно кешироваться, там не хватит ни 32Гб ОЗУ, ни отдельного swap-раздела на 250гб. Тем более, если в это время будет активен zram, то он еще и отожрет на сжатие свопа неплохую такую часть процессорного времени.

Намана, он мне удобен оказался совсем не тем что он сжимает, а тем что тупо не даёт выгружаться данным из оперативки и всё. До этого я свопом как таковым не пользовался (включал/чаю явно только когда надо)

А настройки, ну пусть на все ядра разбросано по дефолту, нагрузки никакой вообще не замечаю, а память в 99% так в том и суть, пускай она вся работает.

А если что жрать будет, ну либо так и надо и тогда ждать и терпеть, либо потекло дуром, но это уже другая история и в целом ситуация не совсем штатная.

Короче установил, минимально настроил, оно работает. Всё. Без какой либо явной необходимости не вижу смысла настраивать по иному. У меня обычный домашний ПК.

Правильно, что включил микрофризы без свопа при 64 гигах памяти. Я тоже раньше как все идиоты отрубал своп. Потом zram врубил, потому как от того что звук в видео попердывает периодически мне ни тепло, ни холодно было. Но мне, чето кажется, что и со zram не так все стабильно работает (хоть и пердежа больше нет)

приоритеты в fstab можно использовать. pri=100, 200 ... 300 https://wiki.archlinux.org/title/swap#Priority

Кстати, я после прведения экспериментов отрубил доп своп на диске для гибернации. Я ее многократно протестировал и выход из гибернации у меня занимает больше времени чем холодный старт (виновато скорее всего zstd вместо дефолтного lz4). Подправил свои кофниги:

~
❯ cat /usr/lib/systemd/zram-generator.conf
# This config file enables a /dev/zram0 device with the default settings:
# — size — same as available RAM or 8GB, whichever is less
# — compression — most likely lzo-rle
#
# To disable, uninstall zram-generator-defaults or create empty
# /etc/systemd/zram-generator.conf file.
[zram0]
#zram-size = min(ram / 2, 8192)
compression-algorithm = zstd

~
❯ cat /etc/sysctl.d/99-swap.conf
vm.swappiness = 200

Но не уверен, что тако свопинес полезен как клубничный йогурт

я в целом не понимаю почему при исчерпании ОЗУ Линукс делает лапки кверху

Все достаточно просто, если разобрать вопрос по частям. Во-первых надо понять, как Linux работает с кодом и данными, которые в исполняемых файлах и библиотеках. Во-вторых, разобраться, что такое out of memory в понимании ядра. В-третьих, склеить эти два куска новых знаний. Поехали. Для простоты, будем считать, что swap’а нет, но это непринципиально.

В Linux есть два вида страниц памяти (переупрощаю): анонимная память и файловый кеш. Приложение может попросить кусок памяти и использовать на чтение и запись, как ему заблагорассудится - это анонимная память. А еще приложение может сказать «mmap», т.е. «дай мне фальшивый кусок памяти, а при попытках из него прочитать - давай мне данные вот из этого файла». При этом по факту ненужные куски файла не читаются. Ядро кеширует прочитанное в ОЗУ. За счет этого файлового кеша, пока он не сброшен, по производительности такая фальшивая память не отличается от обычной. Так вот, программы и библиотеки всегда грузятся через mmap.

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

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

Затем пользователь таки переключает вкладку с pikabu на gmail. Ой, а код переключения вкладок из памяти выброшен! Надо вернуть его на место путем чтения с диска, пока никто не заметил… а вот некуда, так как свободных страниц нет. Ну, есть код отображения картинок, он большой и ненужный, давайте часть его выкинем, а код для переключения вкладок прочитаем. Переключили вкладку. Ой, а сейчас надо рисовать картинку, а код выброшен! Надо этот код загрузить, а что-то ненужное выбросить. Вот есть вторая половина распаковщика картинок, давайте выбросим ее, а первую половину прочитаем с диска. Ура, прочитали и выполнили… вот только опять приходится выполнять выброшенный код. Да ничего страшного, так и будем барахтаться по-собачьи, без паники, прогресс есть (!!!), убивать пользовательские процессы нет необходимости. Вот только получился процессор, работающий по факту на частоте 1 MHz, а остальное время ждущий, пока прострекочет диск, и пользователь, с точки зрения которого все зависло.

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

MGLRU, которое уже в официальном ядре. По факту оно тоже не работает.

А в чем это выражается?

Я ничего такого не заметил, наоборот с MGLRU стало лучше. Могу открыть сотни закладок в браузере - забьется вся память и попытается в течении длительного времени забить своп (zram), но система так и не зависнет намертво, как раньше. А уж прихода oom-killer (nohang) давно не видел.

На десктопе действительно работает. В отличие от le9, где объем невытесняемого файлового кеша является параметром, в MGLRU таким параметром является возраст страниц с момента последнего обращения. Это позволяет защитить от вытеснения в точности working set, что актуально для десктопа.

А вот на сервере первое, что будет делать админ при таком забивании памяти, это подключение по ssh. Упс, sshd - это не часть working set, и, в отличие от le9 и prelockd, под защиту MGLRU не попадает. Действительно, туда при нормальной работе сервера никто не пытается подключиться, кроме хакеров, которых уже отсеял fail2ban. Итог - удаленное подключение тупит десятки секунд, прежде чем показать командную строку bash.

На самом деле по работе приходится поддерживать определенное кластерное ПО. И там в одном из компонентов есть небольшая утечка памяти. Память течет при условии, что кластер работоспособен, и определенные настройки выставлены в определенные значения. Так вот, память и текла понемногу, пока софтина не стала подтормаживать настолько, что не смогла убедить себя, что является частью работоспособного кластера. Утечка так сама себя заткнула. А вот памяти осталось совсем мало, а причин у ядерного OOM-киллера что-то убивать в итоге нет и не предвидится. Если бы такого самозатыка не было, то OOM-killer бы софтину прибил и узел кластера бы сам восстановился. А так пришлось перезагружать по-плохому через IPMI.

ещё пользователь был виноват, а то недавно https://dupeguru.voltaicideas.net/ использовал, и раньше пользовался, нормально было, а чо-то раз и 20 гигов сожрало и тормозить начало, хорошо заметил и прибил