LINUX.ORG.RU

zram-tools как правильно сконфигурировать?

 , ,


0

2

cat /etc/default/zramswap

#CORES=1
PERCENTAGE=95
#ALLOCATION=256
PRIORITY=100

free -m

              total        used        free      shared  buff/cache   available
Mem:           3946        2702         144         203        1099         820
Swap:          3748           5        3743

zramctl

NAME       ALGORITHM DISKSIZE  DATA  COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram1 lzo           1.9G  2.4M 722.1K  1.2M       2 [SWAP]
/dev/zram0 lzo           1.9G  2.5M 686.5K  1.1M       2 [SWAP]

sysctl vm.swappiness

vm.swappiness = 60 # менял на 10 - такая же история

т.е озушка занята 2.85гб из 3.85, а в zram всего 5мб данных

vm.swappiness уже давно обозначает не активность свопинга (если не 0=отключено), а баланс какие страницы свопить. И лично мне кажется что в районе 60-100 свопинг более отзывчив чем при 10. Но это не точно.

2702/3946 это пока что не выглядит тем пределом, с которого стоит начинать свопинг. Особенно если где то в tmpfs не подвисло гигабайта каких нибудь данных или видеодрайвер не начал течь на гигабайты разделяемой памяти. Короче грузи больше и увидишь свопинг. Правда не имея реального свопа ты всего лишь оттягиваешь момент, когда система встанет раком.

А ещё я считаю что zram-tools это бесполезный мусор и настроить zram проще написав всё что надо в загрузочный скрипт. И ещё что zswap однозначно не должен работать паралельно с zram, и в этом стоит убедиться (на дебиан9 он по умолчанию собран и возможно даже включен). И ещё точно не известно какая из двух подсистем более эффективна.

kirill_rrr ★★★★★ ()

О, и 4 гектара zram из 4 гектар может внезапно плохо аукнуться. Говорят в среднем содержимое памяти сжимается в 2-3 раза. Но как известно что то может пойти не так и данные не сожмутся и займут почти всю доступную память, а приложениям останется шиш.

kirill_rrr ★★★★★ ()

#CORES=1

На свежих ядрах и не сильно свежем zram-tools нужно явно задать CORES=1, а не оставлять значение по умолчанию. Раньше каждое zram устройство могло использовать только одно ядро, поэтому их делали несколько. У тебя, вон, видно, что каждое из двух сжимает в два потока, итого четыре. А ядер у тебя, похоже, только два.

В свежих zram-tools этот параметр убрали за ненадобностью. И там всегда создаётся одно zram устройство.

PERCENTAGE=95

Нет смысла ставить больше 50. Если оставить CORES=1, то наверняка больше 50 и не получится включить.

lzo

Бери zstd. Скорость сжатия немного похуже, зато степень сжатия лучше.

vm.swappiness

Можешь поставить 100, но разницы с 60 вряд ли заметишь. Играться имеет смысл только если у тебя своп на устройстве, которое относительно плохо обрабатывает случайный доступ.

озушка занята 2.85гб из 3.85, а в zram всего 5мб данных

Это нормально. У тебя 820 мегабайт доступно, из них 144 вообще ничем не занято, даже кешем. Бессмысленно пихать данные в своп, это только хуже сделает.

i-rinat ★★★★★ ()
Ответ на: комментарий от hakavlad

А я накалывался уже при 50%. При гиге оперативки правда, но… Жалких 400М=45% памяти одному приложению не удалось выделить и свопинг был реально бесконечным и бессмысленным. А ещё у меня есть ненулевая вероятность забить tmpfs пачками jpeg и png миниатюр, которые лягут в zram и не будут оттуда запрашиваться сутками.

Короче сейчас я склоняюсь к мысли, что более примитивный zswap при интенсивном свопинге будет работать лучше.

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Бери zstd. Скорость сжатия немного похуже, зато степень сжатия лучше.

zstd (since linux-4.18), lz4 (since linux-3.15), or lzo.

Size: zstd (best) > lzo > lz4. Speed: lz4 (best) > zstd > lzo

Считал по описанию zram-init, что для слабых машин lz4 поинтереснее, и хрен с ним с сжатием.

One ★★★★★ ()
Ответ на: комментарий от kirill_rrr

Жалких 400М=45% памяти одному приложению не удалось выделить и свопинг был реально бесконечным и бессмысленным.

А не та же ли это проблема, которую вскрыл Ташкинов? Точно ли проблема в zram?

https://www.opennet.ru/opennews/art.shtml?num=51231

anonymous ()
Ответ на: комментарий от anonymous

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

kirill_rrr ★★★★★ ()

Лучшие практики такие. Если речь о недревних ядрах.

Во-первых, изучите оф док https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html

Далее по пунктам:

1) Load Module

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

2) Set max number of compression streams

Можно не менять ничего - по умолчанию число потоков сжатия равно числу потоков цп

3) Select compression algorithm

Начиная с 5.1 по дефолту lzo-rle - ускоренный lzo. Достаточно хорош. zstd имеет смысл брать если степень сжатия важнеее скорости сжатия.

4) Set Disksize

Там же:

Note: There is little point creating a zram of greater than twice the size of memory since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the size of the disk when not in use so a huge zram is wasteful.

Не имеет смысла ставить disksize (макс размер несжатых данных) больше двух MemTotal. disksize, равный MemTotal - это отлично.

При большом disksize (> MemTotal), при попытке сжатия несжимаемых данных, устройство zram может занять всю память. Это нежелательное состояние умеет лечить юзерспейсный киллер nohang при выставлении zram_checking_enabled=True в его конфиге. С ним можнор не бояться больших дисксайзов.

5) Set memory limit: Optional

Это лимит на размер сжатых данных. При упирании в этот лимит журнал будет завален ошибками и возможно его повреждение. Не рекомендуется ставить выше нуля - дефолт оптимален.

Резюме

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

disksize = 100% MemTotal достаточно безопасен. С nohang с включенной проверкой размера сжатых данным можно не бояться ставить disksize > MemTotal.

Демо сжатия несжимаемого с большим disksize: https://www.youtube.com/watch?v=o6GOz95sAnY - мошенник быстро убит.

anonymous ()
Ответ на: комментарий от kirill_rrr

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

Смотри:

	 * Global reclaim will swap to prevent OOM even with no
	 * swappines

https://github.com/torvalds/linux/blob/master/mm/vmscan.c#L2263

anonymous ()
Ответ на: комментарий от anonymous

Global reclaim будет заменяться, чтобы предотвратить ООМ даже без подкачки, но пользователи memcg хотят использовать эту ручку, чтобы полностью отключить подкачку для отдельных групп, когда использование функции ограничения подкачки контроллера памяти было бы слишком дорогим.

Не применяйте никакого умения балансировки давления, когда система близка к ООМ, сканируйте как Анон, так и файл одинаково (если только настройка swappiness не противоречит swapping).

Не вижу здесь ничего, что бы говорило о снятии запрета свопинга. Можно было бы потестить, но я сегодня пас.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от anonymous

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

На данный момент получается, что «{Глобальные требования?! Настройки? необходимось?} будут свопить чтобы предотвратить oom даже если отсутствует {swappiness}, но пользователи {контрольных групп по памяти} хотят использовать эту настройку чтобы запретить свопинг отдельным группам когда использование {управления лимитом свопа через memcg} слишком затратно».

Но это всё ещё ничего не говорит о поведении при vm.swappines=0

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от anonymous
  1. Set memory limit: Optional Это лимит на размер сжатых данных. При упирании в этот лимит журнал будет завален ошибками и возможно его повреждение. Не рекомендуется ставить выше нуля - дефолт оптимален.

https://github.com/hakavlad/yazram - мой скрипт для настройки zram с хорошими дефолтами, можешь попробовать.

ZRAM_MEM_LIMIT=$(( MEMORY_TOTAL * ZRAM_MEM_LIMIT_FRACTION / 100 )) echo $ZRAM_MEM_LIMIT > /sys/block/zram0/mem_limit

Не прошел проверку временем mem_limit? В 2021 году желательно его оставить дефолтным, равным 0?

anonymous ()