☰

Какое значение vm.swappiness является подходящим при использовании zram?

tag-icon • tag-icon memory linux-kernel swap ram zram
Какое значение vm.swappiness является подходящим при использовании zram?

Я использую zram на своем компьютере в качестве сжатого свопа с поддержкой RAM. Когда системе нужно что-то выгрузить, выгрузка в файл подкачки с поддержкой zram более или менее эквивалентна сжатию этих данных в памяти для освобождения места. Это делает подкачку очень быстрой большую часть времени по сравнению с подкачкой с поддержкой диска. Из-за этого мне интересно, можно ли повысить производительность, поощряя систему выгружать неиспользуемые вещи более агрессивно, поскольку она может делать это, фактически не затрагивая диск?

Так кто-нибудь пробовал, например, установить vm.swappinessзначение 100 при использовании zram? Будет ли это желательно?

sysctl -w vm.swappiness=100

решение1

Короткий ответ: vm.swappiness=100естьсоответствующее значениедля zram (по крайней мере на Debian Stretch с Linux 4.9, я считаю, что это лучшее значение)

Я уже тестирую vm.swappiness=100себя.

Я думаю, ты сможешь сделатькакой-то простой тестчтобы убедиться, какое значение является наилучшим для вас.

Также я сделалеще одна простая программадля проверки этого вопроса. x На моем компьютере очень низкое vm.swappinessзначение (такое как vm.swappiness=1) вызовет очевидную проблему с откликом.

О нас SwapCachedв /proc/meminfo:

Сначала попробуйте vm.page-cluster=0этовозможно, можно сократить некоторые бесполезные моменты SwapCachedот замены.

SwapCached может ускорить zram так же, как и устройство подкачки без zram

SwapCachedможно использовать повторно (бесплатно) при необходимости:

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$

решение2

Я бы не рекомендовал ставить swappiness выше. Обычный механизм в ядре заключается в том, что оно помещает страницы (куски памяти) в swap, чтобы освободить часть памяти для других запущенных задач.

Первая «проблема» возникает, когда ядру требуется освободить n страниц, m (при m < n, m — количество сжатых страниц, необходимых для хранения n) вновь создаются в оперативной памяти. Я не уверен, может ли это нарушить работу ядра или нет.

В любом случае, когда у вас есть страницы в свопе, возможно, вы используете приложение позже с некоторыми из его страниц в свопе. Ядро возвращает эти страницы в физическую память, но не удаляет их из свопа (что в стандартном свопе можно рассматривать каккэширование, поэтому, когда приложение возвращается в фоновый режим, ядру не нужно записывать эти страницы обратно в медленный своп). Однако с zram это, возможно, не самый разумный трюк, потому что тогда у вас в памяти будет m страниц в zram + n страниц, которые вернулись в память!

Ядро обычно имеет "общую память", которую оно может использовать для своих дел. Когда вы добавляете zram, он учитывает только память "свопа", как это было бы с любым свопом на основе диска, но это уменьшает фактическую "общую память", и это не ожидается ядром. Иногда из-за этого вы можете иметь странное и нежелательное поведение!

С zram было бы хорошо, если бы ядро ​​не подкачивало слишком много в эту область, когда оно находится под давлением памяти. И у вас всегда должен быть реальный раздел подкачки жесткого диска, по крайней мере, больше максимального размера вашего zram, чтобы система не получила OOM, в то время как в то же время вы увидите много свободного места, как сообщает free!

решение3

https://wiki.archlinux.org/title/Zram#Оптимизация_подкачки_на_zram

Эти значениячто использует Pop!_OS. Этот запрос на извлечение Pop!_OS GitHub также ссылается нанекоторые тесты, проведенные пользователями на r/Fedora, который определил, что vm.page-cluster = 0 является идеальным. Они также обнаружили, что высокое значение swappiness является идеальным, что соответствует тому, что предлагаетсяДокументация ядра:

Значение по умолчанию — 60. Для подкачки в памяти, например zram или zswap, а также гибридных установок, в которых подкачка выполняется на более быстрых устройствах, чем файловая система, можно рассматривать значения, превышающие 100. Например, если случайный ввод-вывод на устройстве подкачки в среднем в 2 раза быстрее ввода-вывода из файловой системы, то подкачка должна быть 133 (x + 2x = 200, 2x = 133,33).

решение4

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

Связанный контент