Значение swappiness при использвании ZRAM

У меня 3000мб/c.

Не увидел там никаких подтверждений мифического высвапления кэша.

Кстати, решил проверить рекомендацию про увеличение swappiness при использовании zram. Выставил 150. Действительно, отзывчивость при нехватке памяти стала лучше.

Достаточная. Часа в 4 укладываюсь.

А по сравнению с числом потоков, при котором в свап не(слишком) лезет?

Не экспериментировал, если честно. Сейчас стоит MAKEOPTS="-j17", поставлю -j9 и замерю время.

Зачёт за аватарку.

Кто что посоветует?

Оставил дефолтные значения системы.

200

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

What should my swappiness setting be?
First, it's important to understand what vm.swappiness does. vm.swappiness is a sysctl that biases memory reclaim either towards reclamation of anonymous pages, or towards file pages. It does this using two different attributes: file_prio (our willingness to reclaim file pages) and anon_prio (our willingness to reclaim anonymous pages). vm.swappiness plays into this, as it becomes the default value for anon_prio, and it also is subtracted from the default value of 200 for file_prio, which means for a value of vm.swappiness = 50, the outcome is that anon_prio is 50, and file_prio is 150 (the exact numbers don't matter as much as their relative weight compared to the other).

This means that, in general, vm.swappiness is simply a ratio of how costly reclaiming and refaulting anonymous memory is compared to file memory for your hardware and workload. The lower the value, the more you tell the kernel that infrequently accessed anonymous pages are expensive to swap out and in on your hardware. The higher the value, the more you tell the kernel that the cost of swapping anonymous pages and file pages is similar on your hardware. The memory management subsystem will still try to mostly decide whether it swaps file or anonymous pages based on how hot the memory is, but swappiness tips the cost calculation either more towards swapping or more towards dropping filesystem caches when it could go either way. On SSDs these are basically as expensive as each other, so setting vm.swappiness = 100 (full equality) may work well. On spinning disks, swapping may be significantly more expensive since swapping in generally requires random reads, so you may want to bias more towards a lower value.

The reality is that most people don't really have a feeling about which their hardware demands, so it's non-trivial to tune this value based on instinct alone – this is something that you need to test using different values. You can also spend time evaluating the memory composition of your system and core applications and their behaviour under mild memory reclamation.

When talking about vm.swappiness, an extremely important change to consider from recent(ish) times is this change to vmscan by Satoru Moriya in 2012, which changes the way that vm.swappiness = 0 is handled quite significantly.

Essentially, the patch makes it so that we are extremely biased against scanning (and thus reclaiming) any anonymous pages at all with vm.swappiness = 0, unless we are already encountering severe memory contention. As mentioned previously in this post, that's generally not what you want, since this prevents equality of reclamation prior to extreme memory pressure occurring, which may actually lead to this extreme memory pressure in the first place. vm.swappiness = 1 is the lowest you can go without invoking the special casing for anonymous page scanning implemented in that patch.

The kernel default here is vm.swappiness = 60. This value is generally not too bad for most workloads, but it's hard to have a general default that suits all workloads. As such, a valuable extension to the tuning mentioned in the «how much swap do I need» section above would be to test these systems with differing values for vm.swappiness, and monitor your application and system metrics under heavy (memory) load. Some time in the near future, once we have a decent implementation of refault detection in the kernel, you'll also be able to determine this somewhat workload-agnostically by looking at cgroup v2's page refaulting metrics.

уже 32

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

лучше всегда протестировать на практике. мне лично помогало только его поднятие

правда это было на 2гб озу

из моих игр с этим параметром на федоре 32(при заполнении оперативки):
чем ближе значение к 0, тем чаще случались фризы и дольше фризит
чем больше к 100 (выше не пробовал), наоборот реже
лучше оставить дефолт
при появлении траблов искать причину
ну или поставь tuned, оно само что-то там тюнит в том числе и swappiness

Swap 64МБ идеальное решение.

Но ведь с таким значением я не смогу компилить ядро с -j300. А если свопа 14гиг - то смогу.

а нужно ли это говно при 16гиг озу-то?

да, машоб, моделирование, 3д, виртуалки

https://youtu.be/O8QNnfb_Vm0 - вот тут swappiness=100, и стресс не мешает отзывчивости. zram - 3/2 озу.

У меня 16GB RAM, на ZRAM swap на 8GB Чтобы побольше данных в сжатый в своп кидало поставил: cat /proc/sys/vm/swappiness 100 cat /proc/sys/vm/vfs_cache_pressure 1000 cat /proc/sys/vm/watermark_scale_factor 1000