Убунтята, не проходите мимо: le9 patch добавлен в linux-xanmod и ваш OOM killer будет вылечен

zram? Не знаю. Ядро дефолтное 3.13. Вручную ничего не настраивал.

ставь свечку за выздоровление

А чо? Неплохой комп. Core2Duo тоже есть, как и двухъядерный Athlon.

zram? Не знаю. Ядро дефолтное 3.13

на 3.13 zram нет, на более новых - есть.

для тебя ж заметка https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/

и вот ещё для тебя заметка: https://www.google.ru/books/edition/Overcoming_Compulsive_Hoarding/aPJ4gmKSY4QC

если у меня червёртый пень прескотина с 1 Гб памяти, мне что ставить надо?

256MB RAM is recommended minimum for antiX https://ru.wikipedia.org/wiki/AntiX

ушел с своп на 18ГБ и до сих пор не завершился.

Чо-т я не понял. Если:

1. Сжатые в zswap страницы идут в статистику занятого свопа как если бы они были не сжаты.
2. OOM честно приходит, когда закончилось место и в свопе, и в оперативной памяти.

то как тогда можно бесконечно расти?

Так то вроде всё логично, процесс сдох, выжрав память.

то как тогда можно бесконечно расти?

а кто бесконечно растет? рост остановился на 17 ГБ.

Ну тогда я не понял, что ты оверкоммитом хотел подкрутить.

У меня tail умирает, имея около 10 ГБ VSIZE.

Вот пример.

uniq /dev/zero

с overcommit=1 выжирает всю память и приходит оом

c overcommit=0 выжирает не всю память, падает с cannot allocate memory

Я подумал, что здесь может быть также.

uniq /dev/zero

c overcommit=0 выжирает не всю память, падает с cannot allocate memory

Странно.

Чтобы ядро вернуло отлуп с overcommit=0, нужно попытаться выделить регион заведомо больше оперативки и свопа, ЕМНИП.

Все так. Может uniq это и делает на определенном этапе.

BTW, zswap-monitor https://github.com/hakavlad/nohang-extra/blob/master/zswap-monitor2

Показывает степень сжатия и сколько пула занято - абсолютно и относительно. Хорошо переносит нехватку памяти.

Пример вывода

$ sudo ./zswap-monitor2
[sudo] пароль для user: 
pool: 0.0 MiB (0.0% MemTotal) | stored: 0.0 MiB (0.0% SwapUsed) | compr_ratio: 0.0
pool: 0.0 MiB (0.0% MemTotal) | stored: 0.0 MiB (0.0% SwapUsed) | compr_ratio: 0.0
pool: 0.0 MiB (0.0% MemTotal) | stored: 0.0 MiB (0.0% SwapUsed) | compr_ratio: 0.0
pool: 0.0 MiB (0.0% MemTotal) | stored: 0.0 MiB (0.0% SwapUsed) | compr_ratio: 0.0
pool: 0.0 MiB (0.0% MemTotal) | stored: 0.0 MiB (0.0% SwapUsed) | compr_ratio: 0.0
pool: 234.1 MiB (2.4% MemTotal) | stored: 503.9 MiB (93.1% SwapUsed) | compr_ratio: 2.2
pool: 614.0 MiB (6.3% MemTotal) | stored: 1304.1 MiB (96.6% SwapUsed) | compr_ratio: 2.1
pool: 1030.9 MiB (10.5% MemTotal) | stored: 2164.9 MiB (97.7% SwapUsed) | compr_ratio: 2.1
pool: 1464.8 MiB (15.0% MemTotal) | stored: 3032.8 MiB (98.3% SwapUsed) | compr_ratio: 2.1
pool: 1878.7 MiB (19.2% MemTotal) | stored: 3861.0 MiB (98.7% SwapUsed) | compr_ratio: 2.1
pool: 2283.5 MiB (23.3% MemTotal) | stored: 4672.4 MiB (98.9% SwapUsed) | compr_ratio: 2.0
pool: 2683.3 MiB (27.4% MemTotal) | stored: 5471.7 MiB (99.1% SwapUsed) | compr_ratio: 2.0
pool: 3071.7 MiB (31.4% MemTotal) | stored: 6248.6 MiB (99.2% SwapUsed) | compr_ratio: 2.0
pool: 3430.3 MiB (35.1% MemTotal) | stored: 6965.7 MiB (99.3% SwapUsed) | compr_ratio: 2.0
pool: 3742.8 MiB (38.3% MemTotal) | stored: 7163.9 MiB (99.3% SwapUsed) | compr_ratio: 1.9
pool: 680.0 MiB (7.0% MemTotal) | stored: 1441.2 MiB (96.6% SwapUsed) | compr_ratio: 2.1
pool: 679.8 MiB (6.9% MemTotal) | stored: 1440.4 MiB (96.6% SwapUsed) | compr_ratio: 2.1
pool: 679.8 MiB (6.9% MemTotal) | stored: 1440.4 MiB (96.6% SwapUsed) | compr_ratio: 2.1
pool: 679.8 MiB (6.9% MemTotal) | stored: 1440.4 MiB (96.6% SwapUsed) | compr_ratio: 2.1
pool: 679.6 MiB (6.9% MemTotal) | stored: 1439.4 MiB (96.6% SwapUsed) | compr_ratio: 2.1
^C

zram и zswap слабо совместимы:

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

?

он zram вроде и не использует

ты ж только с zswap?

Поставил zswap на треть ОЗУ, послежу за разницей.

после удаления zram?

Неужели он так эффективно жмет?

Не он эффективно жмет, а просто данные легкосжимаемые - tail раздувается нулями. Вот как это выглядит на пике, когда 17ГБ в свопе:

disksize:          38.217 GiB
orig_data_size:    17.386 GiB
mem_used_max:       1.200 GiB
mem_used_total:     1.196 GiB
compr_data_size:    1.115 GiB

как вам свежая статья

Настройка ядра Linux для повышения производительности памяти https://habr.com/ru/company/otus/blog/566970/

о чем статья?

Также рекомендуется либо уменьшать параметр swappiness до нуля, либо не использовать своп. В любом случае для операций с низкой задержкой использование свопа резко снизит производительность.

https://habr.com/ru/company/otus/blog/566970/

Да они с ума сошли.

tail раздувается нулями

Я ж специально не нулями его грузил.

swappiness до нуля

Бред.

У кого акк есть, дайте им там ссылку на патч и на объяснение логики работы.

Это копипаста

Ну у тебя может не нули, но легкосжимаемый текст. Тексты отлично сжимаются.

mem-load выше - вот там случайные числа и невысокая степень сжатия, пробуй это. Это более реалистичная нагрузка получится.

Сжатые в zswap страницы идут в статистику занятого свопа как если бы они были не сжаты.

zswap — сжатый буфер, до попадания в своп, как это может попасть в «статистику занятого свопа»? (При этом Zswap абсолютно точно разжимает страницы при выгрузке в swap устройство, потому как кроме zswap никто не в курсе, что страницы сжаты).

А вот если в процитированной фразе zswap заменить на zram, то всё правильно, так оно и есть.

zswap — сжатый буфер, до попадания в своп, как это может попасть в «статистику занятого свопа»?

Это нужно спросить у авторов ядра.

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

А вот если в процитированной фразе zswap заменить на zram, то всё правильно, так оно и есть.

У меня выключен zram.

Это копипаста

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

Вот так весь инет заполняется маркетинговым и SEO-шным мусором :(

страницы учитываются в статистике при их упаковке в сжатый кэш

Да. На бумаге своп занят, по факту в свопе нарисован объем несжатых страниц, которые на самом деле таки сжаты в пуле zswap.

Это нужно спросить у авторов ядра.

код можно см не спрашивая

Интересно, что пути Fedora и Archlinux на данном этапе разошлись: первые включили по-умолчанию zram, вторые — zswap.

А пруф?

Арч и «что-то по умолчанию» — понятия несовместимые.

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

Там же заголовок

Настройка ядра Linux для повышения производительности памяти

Не сказано «Настройка ядра Linux для повышения общей производительности». У памяти может и растет производительность, да только общая производительность может падать, потому что узким местом обычно является IO, а не память. Оптимизировать-то надо узкие места.

На бумаге своп занят, по факту в свопе нарисован объем несжатых страниц, которые на самом деле таки сжаты в пуле zswap.

Страницы ещё не выгружены в своп, но уже как бы занимают в нём место, правильно я понимаю?

Интересно, что пути Fedora и Archlinux на данном этапе разошлись: первые включили по-умолчанию zram, вторые — zswap.

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

Да, на бумаге они в свопе, а по факту в сжатом пуле.

при запуске tail /dev/zero диск не мигает с zswap - на бумаге растет занятость свопа, а по факту диск не задействован, идет быстрое сжатие памяти.

Арч и «что-то по умолчанию» — понятия несовместимые.

Тем не менее конфиг сборки ядра существует

https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/config#L1082

https://wiki.archlinux.org/title/Zswap#Toggling_zswap

(В linux-lts аналогично, т.е. zswap включен по-умолчанию; в linux-zen не проверял)

Ничего себе. Спасибо.

У меня прежде он в /etc/systemd/swap.conf был отключен.

То есть если я просто снесу этот конфиг, по умолчанию всё равно будет zswap. Забавно…

А ты проверь, без снесения конфига. Может автор systemd-swap ещё не понял, что умолчания сменились.

grep -R . /sys/module/zswap/parameters

А вот зачем страницы разжимать перед записью?

Непонятный момент.

Читал объяснение — так как в своп могут попадать страницы как после zswap, так и напрямую, то надо разжимать. Хотя, по моему разумению, можно было бы сделать отдельное своп-устройство для сброса сжатых страниц из zswap.

Хотя, по моему разумению, можно было бы сделать отдельное своп-устройство для сброса сжатых страниц из zswap.

Тоже так думаю.

https://gitlab.com/post-factum/pf-kernel/-/commit/0af9a997d0386ded3414f73e29d7119eedfaf624

Не тестил.

https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/en/

https://news.ycombinator.com/item?id=27795119

https://www.reddit.com/r/linux/comments/ohn6an/linux_for_pc_from_2007_37_browser/

Сделал отдельную заметку

Мне вот интересно, а кто-нибудь на одноплатниках подобное пробовал провернуть? ОЗУ им не хватает даже при довольно приличном процессоре.

В Armbian (да и везде, наверное) включён zram. А как десктопом ими никто не пользуется — нет драйверов для нормального графического ускорения десктопа, декодирования видео (в браузере) и т.п.

А как десктопом ими никто не пользуется

Поэтому никто и не пользуется - оно тормозит как ни в себя.

нет драйверов

Ну с этим уже попроще. А вот с объёмом памяти засада.