LINUX.ORG.RU

нехватка ram для жирных пакетов

 , ,


0

1

Привет всем, использую генту, 16gb и zram 4gb сжатие zstd, zram-init за это все отвечает, но к сожалению уже и этого не хватает а использовать для сборки nvme как то не особо хочется

  1. поможет ли мне смена сжатие с zstd на более мощное

2)в zram-init не вижу флаг где можно увеличить либо уменьшить степень сжатие(или оно не влияет)

  1. если 1 вопрос да поможет то как мне сделать второй слот zram с этим сжатием чтобы он сработал после заполнение первого слота более быстром сжатием

  2. сильно не бейте плиз

P.s. покупка больше плашок или HDD не имеется возможно

P.s.s как выглядит сейчас

load_on_start="yes"

unload_on_stop="yes"

num_devices="2"

type0=swap
size0=$(( 1024 * 4 ))
maxs0=4
algo0=zstd level=19
labl0=zram_swap
cat /etc/fstab
#boot
UUID=4848-C9DD                            /efi        		vfat  defaults		0 2
#/efi/EFI/gentoo 			 /boot 		none  defaults,bind 	0 0

#system
UUID=0be087b8-ca5d-4e19-b12e-84af41c0e631 /                	btrfs compress=zstd:1,defaults,noatime,discard=async,autodefrag,subvol=/@ 0 0
UUID=6a25019e-9a20-43fb-8e81-9708cfb36219 /mnt/disk2 		btrfs compress=zstd:1,defaults,noatime,discard=async,autodefrag,auto 0 0

#tmps
tmpfs					 /var/tmp/portage tmpfs size=14G,uid=portage,gid=portage,mode=775,nosuid,noatime,nodev 0 0
tmpfs 					 /tmp 		  tmpfs rw,nosuid,noatime,nodev,size=4G,mode=1777 0 0
tmpfs                                     /run             tmpfs size=100M
★★

Последнее исправление: SPRATAY (всего исправлений: 3)

Ответ на: комментарий от SPRATAY

Я понимаю, что это проще всего, но портить nvme как то не хочется, поэтому написал что свап раздел не особо охота

Он у тебя всё равно испортится. Всё равно данные нужно на HDD сбрасывать, без этого никак.

Kroz ★★★★★
()

Используй zswap вместо zram, ту же tmpfs, физический своп на nvme (большой чтобы ftl было где развернуться) и не парься о ресурсе. Там пики будут довольно редкие и сжатие их сильно проглотит.

Могу предложить с десяток опций оптимизации которые проверял у себя.

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

Но странно, с 16 гб в генте даже сложные пакеты собирались в 4 потока.

Можно собирать много пакетов в малое число потоков. Там крайне редко пики жирного пакета будут накладываться друг на друга. Если всё совсем встанет раком можно вручную один из процессов поставить на паузу.

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

Вилами на воде. Поток может и 10М ограничиться если там действие мелкое, а бывало что в ~2015 году 1 поток за 4гб переваливал. А ld на финальном этапе сборки файерфокса стабильно выжирал 8гб и уходил в своп. Это ещё до того как профилирование придумали.

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

пока не крякнет (в самый ответственный момент)

О боже, ld упадёт вовремя сборки! И ещё пара процессов, потом потребуется презагрузка... Но вот данные на диск будут сброшены т.к. драйвера ФС не вытесняются!

kirill_rrr ★★★★★
()

4gb сжатие zstd

zstd сжимает сильнее. Но зачем сжимать сильнее, если disksize маленький?

Рекомендую вернуть дефолтный сжиматель lzo-rle - сжимает хуже zstd, но работает быстрее.

Увеличьте смело zram disksize до 32 GiB.

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

Эффективность zram/zswap традиционно тестируют именно временем компиляции с использованием tmpfs. Как раз в этом сценарии. И среднестатистический баланс стабильно положительный.

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

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

Вот поэтому zswap! Он просто сжатый кеш, который ещё не сброшен на диск но уже занимает в памяти меньше своего объёма. А ещё неплохая профилактика своп-трешинга когда страница сбрасывается в своп и тут же дёргается обратно.

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

Да не... сейчас всё что больше 100 объёмов это уже почти элита. Тут натуральный mlc должен быть на весь объём, с космической ценой.

Ну либо самсунг врёт, либо они 600TBW из 1Тб сделали на tlc. А qlc просто не нужно покупать. Никогда.

Проверил, ADATA XPG Gammix S11 тоже обещают 600 объемов: «Ресурс накопителя составляет внушительные 1280 TBW». Это на 2Тб.

Думаешь они всё врут?

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

tlc это максимум 150-200 объёмов. Я весной только серверники видел с большими значениями, но там slc/mlc кеш на четверть объёма. Да, я думаю они врут.

Хотя по данным каких то тестеров ~7-10 лет назад в среднем ссд накрывались где то в районе 500-1000% TBW. Может просто политику подсчёта скоректировали.

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

tlc это максимум 150-200 объёмов. Я весной только серверники видел с большими значениями, но там slc/mlc кеш на четверть объёма.

Но там же ещё есть запас «неразмеченный», за счет него наверное тоже. +DRAM кэш есть, короткоживущие данные, возможно даже и не попадут в ячейки. Да и вообще, смерть от исчерпания ресурса это самое безболезненное, что может случится. Ну куплю новый, когда этот в RO перейдет. Всяко не раньше 10 лет исчерпание произойдет(и это очень пессимистичный вариант). Вот смерть контроллера это уже плохо, данные можно незабэкапленные потерять, а RO - не страшно.

Да, я думаю они врут.

Вроде я где-то тесты независимые видел и обычно реальные циклы записи наоборот в большую сторону уходили, чем в меньшую. Если память не подводит, то у сосунга за лям переваливало, вместо 600.

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

https://3dnews.ru/938764/resursnie-ispitaniya-ssd-obnovlyaemiy-material/page-...

Вот по ссылке большое тестирование. Старовато, но показательно. Самый плохой результат 356ТБ на 250Гб, умножаем на 4 и получаем 1200TBW для 1Тб. Это не заявленные, а реальные. Получается реальные в 2 раза больше обещаемых.

Ещё нашел статью с критикой этой статьи, но даже после критики и разделив показатели на 3-10 раз как там рекомендуют, останется миниумум 130Тб для терабайтного диска. У меня за 3,5 года пока что только 30Тб записано, т.е. ещё 10 лет проживёт даже в худшем раскладе. А там уже морально устареет.

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

ну так это другое. Одно дело контроллер - другое изчерпание ресурса ячеек флеша.

А исчерпание ресурса ячеек компенсируется немеряным количеством оных… Так что сборкой крупных пакетов на ссд раз в месяц придется очень долго и безуспешно пытаться убить ссд.

Qui-Gon ★★★★★
()

А вот кстати про память - linux ate my R^W поясните плз про выхлоп free.

Вот машина с кучей виртуалок

# free -g
               total        used        free      shared  buff/cache   available
Mem:             376         337          11         249         298          21
Swap:              3           3           0

У меня свободно 21 гиг или 298 buff/cache тоже могут быть запрошены?

На такой же машине без нагрузки весь buff/cache зарепорчен в available

# free -g
               total        used        free      shared  buff/cache   available
Mem:             376          25           9           0         345         351
Swap:              3           0           3

Таки память заканчивается? Я хотел ещё виртуалок добавить…

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

Я протесиировал твою версию, выделил 48gb zram, даже на одном потоке всеравно упирается в нехватку памяти(но кстати он встал дальше чем было при 4гб поэтому взял на заметку)

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

А если просто tmpfs раздел смонтировать как btrfs с жатием zstd чисто для жирных пакетов, я понимаю что это не одно и тоже, но как из один вариантов как уменьшить демедж по диску, или я что то упускаю?

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

И, кстати, 19 уровень сжатия в zstd — это слишком жёстко для цпу. Я наоборот меняю тем патчем уровень с дефолтного третьего на 1. Попробуй пожать файлики с разными уровнями, чтобы оценить насколько 19 уровень на самом деле трагичен.

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

Может немного, а не намного. Только если disksize большой.

Вопрос также: память заканчивается у вас путем того, что весь своп заполнен?

При большом disksize возможен вариант, когда проблема в том, что память физическая занята раздувшимся устройство zram, при этом своп показывается неполным (SwapFree еще есть, но физически памяти нет, некуда сжатые страницы помещать). Для таких случаев zstd может иметь смысл - более сильное сжатие позволит в своп поместить.

Чтоб zstd имел смысл нужен большой disksize, типа 200% от MemTotal или выше.

hakavlad ★★★
()
Последнее исправление: hakavlad (всего исправлений: 3)
Ответ на: комментарий от anonymous

available — это сколько реально доступно для приложений. Превысишь этот лимит — и привет oom killer. Часть buff/cache может засчитываться в пользу available. Точнее cache часть, которую ядро может сбросить, чтобы освободить память, когда она потребуется. Можно вручную:

echo 3 | sudo tee /proc/sys/vm/drop_caches
stabilitron
()
Ответ на: комментарий от SPRATAY

Да вполне хорошая идея. Только не btrfs, она как раз будет много срать на диск и требовать сборки мусора если я правильно понимаю. Вроде ещё где то сжатие было, если в f2fs то просто идеально.

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

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

Там нет этого эффекта и алгоритм влияет только на скорость если со всеми последними патчами... А если без нового zsmalloc - вообще ни на что не влияет! То что не сжимается в 2 или 3 раза - сбрасывается сразу на диск.

Про обязательность использовать zram+backing_dev чтобы не засрать zram"ом оперативку тут как то никто не упомянул!

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 2)
Ответ на: комментарий от hakavlad

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

zstd может иметь смысл - более сильное сжатие позволит в своп поместить

Помнится гугловский инженер накатал некий патч позволяющий провести дополнительное сжатие, Современное состояние обработки нехватки памяти в линуксах: MGLRU и le9 патчи и юзерспейсные киллеры (комментарий):

Компания Google, работающая над усовершенствованием ZRAM, похоже, намерена использовать эту технологию в Chrome OS.


Но практического применения мало можно найти в сети, только такое попадалось.

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от superuser

если бы HDD были надежными - а так купил б.с.на x. энту хреномантию для NAS -сорри кроме мата слов нет. Так один норм (брал 2 одинаковых в зеркало ) - а второй сука каждые пару минут стучит бошками типа калибруется. Менять отказыватся - он же ошибок не выдает, ну стучит - но в итоге калибруется же. Сижу как на бомбе - когда эта тварь рванет и убив все данные скажет ну не шмогла откалиброваться.

В общем вроде и зеркало но вот ощущение что выбросил немалые деньги ибо доверия этому говну нет и стоило оно не дешево. Чую что надо опять покупать HDD ибо речь идет о долговременном хранилище поднимаемом раз в мес для бэкапа - но вот очень хотелось бы что-нибудь не калибрующее головки адским стуком каждые пару минут. Говно сделала тошиба если что. И диски по 4тб всего, 3.5

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

А у меня 3*1ТБ 2,5" стоят, не в зеркале. 2 вообще вынуты из 2 ноутов и юсб-хдд. Просто файлопомойка, все проблемы пока на юсб2.0 шине.

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

Используешь ядро с патчем - вот и применение.

Не, я не про MGLRU. Я там одно время пихал в твою тему разные новшества по zram, что появлялись в новостях. В данном случае речь про add zram recompression documentation.

/sys/block/zramX/recomp_algorithm, /sys/block/zramX/recompress


Суть, впихнуть невпихуемое. ) Больше, больше золота!11

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

Ну если так хвалишь подключу, но я вроде давно задавал такой вопрос так ответа так не увидел как это будет работать в связке например zram, есть ли способ использовать цепочки приоритеты когда память закончилась использовать zram когда закончился zram использовать zswap(видимо нужно создать свап раздел и потом уже создать сам zswap), не понимаю почему нету что то единого

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

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

Просто zram казалось бы более фичастый, но не забывай что это эмулятор блочного устройства! А zswap это конкретно сжатый кеш между оперативкой и физическим свопом.

Zram vs Zswap. Часть 1: практика Пролистай, грубо говоря моё изучение вопроса, правда на примере старых ядер. С тех пор zsmalloc вроде как научился сбрасывать данные на диск и теоретически должен стать лучшим. Возможно ещё что то изменилось.

Также интересный параметр /proc/sys/vm/page-cluster - это сколько штук страниц памяти скидвать на диск 1 пакетом. Экспериментально установил ,что для моего ССД оптимальный диапазон от 16 до 64, слишком много - больше фризов, слишком мало - хуже для контроллера ftl.

Ещё я чисто для себя определил, что на ядре 6.1 лучше отрубать MGLRU - он пищит и всё портит. Также были конфликты с дефолтнми настройками cgrops v1, сейчас вроде не актуально. И разумеется в топку всякие oomd - просто выдели свопа с большим запасом.

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

Да печально что они в паре не работают, чтож пока остановлюсь на монтирование отдельного пространства для сборки с жатием(если бы ещё знать как создать такой раздел)

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

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

Самое для меня важное это сделать чтобы меньше наносить вред nvme, конфиг fstab у меня в самом вопросе

а так примерно что я буду делать

https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#No_space_left_on_device

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

p.s.

gg wp

Кроме того, вы не можете смонтировать nodatacow для каждого подтома. Все параметры монтирования btrfs применяются ко всей файловой системе на основе первого смонтированного субвола. Единственными параметрами монтирования для каждого субтома являются такие, как noatime и noexec.
SPRATAY ★★
() автор топика
Ответ на: комментарий от SPRATAY

Так это всё понятно. И как тут уже замечали - всё крутится вокруг отсутствия у тебя 32-64Гб оперативки которой хватит на всё. И предложили 3 тактики: отказаться от тяжёлых оптимизаций или вообще не собирать эти пакеты а взять бинарник, или не пихать файлы сборки в оперативку, или всё таки универсальный вариант когда всё таки пихать, но за счёт zswap/zram существенно снизить вред. Вот нарурально от 10 до 100 раз. Да и экономия nvme по сути не имеет смысла если он не распаян на метери.

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

я понимаю что мне были предложены многие варианты, но все упирается в то что тебе приходиться выбирать zram или zswap иначе они не могут работать вместе, либо как я пытался создать отдельную дерикторию, но как оказалось что btrfs дублирует правило монтирование(если бы заранее знал я бы переходил бы на zfs) корневого раздела, оставь тогда свой конфиг zswap буду его использовать когда будет необходимо для сборки

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

…но как оказалось что btrfs дублирует правило монтирование(если бы заранее знал я бы переходил бы на zfs) корневого раздела…

Не понимаю, чего ты хочешь добиться. nodatacow - можно хоть к директории отдельной применить, только компрессия с ним всё равно не работает. А у zfs аналогов нет, да и nodatacow под сборку не нужен.

altwazar ★★★★
()
Последнее исправление: altwazar (всего исправлений: 1)