zram, swap и все, все, все

Поставь 512 метров памяти и используй своп.

1. Swappiness в 100 никто не отменял

2. watermark_scale_factor в 1000 никто не отменял

3. vfs_cache_pressure действует только на соотношение выгрузки из оперативки файлового кеша и inode'ов и не действует на вероятность свопа

4. В выводек free я вижу 2 гига полностью свободной оперативки, там даже кеша файлового нет, она вообще не заполнена. Что при этом система должна свопить? Хотя вот, кстати watermark_scale_factor может поправить и это по идее, в некоторых пределах.

Зачем? У тебя процессы могут резко требовать несколько гигабайт рамы?

Передай ядру mem=128M.

watermark_scale_factor

Кстати, в зависимости от того, для чего надо держать оперативку свободной могут быть разные подходы. Можно, например ограничить RAM для одного или нескольких приложений через cgroups

https://wiki.archlinux.org/index.php/cgroups

1. Swappiness в 100 никто не отменял

не помогает в этом никак

2. watermark_scale_factor в 1000 никто не отменял

что это даёт?

4. В выводек free я вижу 2 гига полностью свободной оперативки, там даже кеша файлового нет, она вообще не заполнена. Что при этом система должна свопить?

не должна, но хочется

что это даёт?

watermark_scale_factor:

This factor controls the aggressiveness of kswapd. It defines the
amount of memory left in a node/system before kswapd is woken up and
how much memory needs to be free before kswapd goes back to sleep.

The unit is in fractions of 10,000. The default value of 10 means the
distances between watermarks are 0.1% of the available memory in the
node/system. The maximum value is 1000, or 10% of memory.

A high rate of threads entering direct reclaim (allocstall) or kswapd
going to sleep prematurely (kswapd_low_wmark_hit_quickly) can indicate
that the number of free pages kswapd maintains for latency reasons is
too small for the allocation bursts occurring in the system. This knob
can then be used to tune kswapd aggressiveness accordingly.


kswapd начнёт чаще срабатывать.

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

это как в одном скетче: буквы знаю, слова понимаю, предложения, из них составленные, тоже. а вот, что это всё значит не понимаю.

kswapd начнёт чаще срабатывать.

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

1. Тут вроде бы не я хотел свопить при свободной оперативке

2. При 1000 по идее оно будет свопить реже, но больший объём данных за раз, что как раз даст возможность не запускать kswapd при каждом увеличении занятой памяти на 2 метра

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

Хочу, что своп использовался по полной. Как сделать?

Память забей. У тебя два гига свободной оперативки, даже не под буферами. Компилировать openwrt поставь в 8 потоков.

компилю gcc, он ругается на нехватку памяти, а swap всё равно почти пустой

Чё в vm.overcommit_memory накрутил?

И замени zram на zswap.

ничего

нет swap-раздела

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

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

AFAIK, zswap не обязателен раздел или любая внешняя память.

zswap - это cache для swap'a

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

компилю gcc, он ругается на нехватку памяти, а swap всё равно почти пустой

Ну, есть вероятность, что данные кидаемые в swap плохо сжимаются и поэтому при нехватке памяти туда записывается какое-то количество данных и всё. Оперативки больше нет, а то, что туда кидается просто не сжимается нормально. Соответственно, своп отказался принимать данные, оперативки кончилась совсем и на этом у системы больше данные девать некуда. Такая ситуация вполне реальна для алгоритма сжатия lz4, например. Он очень быстр, но как только становится понятно, что данные плохо сжимаются, он скипает сжатие и идёт дальше.

В данной ситуации zswap + отдельный swap раздел, выглядят хорошим вариантом для быстрого освобождения оперативки, с последующим сбрасыванием лишнего на диск.

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

Или совсем заморочится с zswap (lz4) + zram (zstd) + указать раздел для записи несжимаемых страниц памяти у zram. Всё зависит от того, что хочется получить в результате.

zswap без файла подкачки не работает, т.к. это кэш для свопа. на эту тему на ЛОРе уже обсуждали.

Zswap is a lightweight compressed cache for swap pages. It takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool.