История успеха

столько ненужного гуано в одном списке
бедная память

Нехватка памяти? Не слышал.

// 32 гига

Запусти хорь что-нибудь еще, и твой Линукс повеситься навечно, насилуя hdd.

Ага, а если при этом реально не хватит памяти, то система повиснет намертво, т.к. своп в оперативке.

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

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

А что, страницы принадлежащие zram какие-то особенные и не могут быть выброшены в настоящий своп?

А не проще ли агрессивность подкачки настроить вместо того что бы городить ZRAM Swap?

Этот «костыль» называется swapon -p. Указать zram приоритет больше, чем свопу на диске.

Нет. ZRAM сжимает.

А с ZSWAP?

Нет. ZRAM сжимает.

Попробую.

Понравилась вот эта фраза:

software suddenly got inexplicably slow (until you found the driver chewing on its own tail by trying to decompress itself)

https://lists.freebsd.org/pipermail/freebsd-performance/2012-November/004651....

2012

«RAM extenders» for MS-DOS

Пытаюсь забить память как могу чтобы наконец-то понять брата и товарища лоровца, у которого все жрет, тормозит и «тяжелое»

Дискового свапа нету, только RAM+zRAM

Думаю стоит над этим подумать. Ведь система таки становится неюзабельной если продолжать стараться забивать ее вплоть до исчерпания RAM+ZRAM. Ничего неудивительного, памяти то нет. Но в случае с дисковым свопом ты начинаешь заранее замечать что дело плохо. По ощущениям ZRAM не тормозит вообще, потому ты ничего не подозреваешь до часа икс и система становится колом. Вот мне кажется если соорудить RAM+ZRAM+disk, то можно практически бесплатно пользоваться первыми двумя с большим количеством оперативной памяти чем обычно и потом добавить чуть диска чтобы при исчерпании памяти хотя-бы понимать что нужно что-то закрыть.

В данном посте я еще показал что тупо никак не могу забить 8ГБ памяти вменяемыми средствами. Так как я описал - пользоваться системой никто не будет. Мне тут разве что приходит в голову IDEA+SBT, они могли бы выжрать наверное 8ГБ

В том-то и дело, в linux когда заканчивается RAM, он зависает намертво, насилуя при этом HDD, я как-то задавал вопрос баг с забиванием HDD на 100% на вечно, но всё что понял - такое поведение естественно, нормально, и похвально

как-то удалось забить память (емнип гигов 6) при помощи монги с ее gridfs, заливал туда по не балуйся. можешь тоже попробовать.

Через пару недель у меня будет 128 вместо 64. И один хрен одна задача будет выжирать и свапиться. Процессы разные.

в linux когда заканчивается RAM, он зависает намертво, насилуя при этом HDD

Это 4.2. Если у вас своп на доисторическом накопителе, то не знаю, чего именно вы ожидали.
Если так вышло, что система встала колом в i/o wait без признаков света в конце тоннеля, вызывайте OOM Killer вручную.

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

Если у вас своп на доисторическом накопителе, то не знаю, чего именно вы ожидали

Если своп хоть на каком накопителе, то оно тормозит, но работает, а вот если его нет, то зависнет

Но это уже специализированный случай мне кажется, даже не 1% таких десктопов есть

Согласен. Я тупо похвастался.
А если серьезно, то при нынешних ценах на память (я вот 64гб ддр4 покупаю за 16к руб) грех экономить эти спички.

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

Ну я не собираюсь экономить. Я немного не то хотел сказать. Я обьективно без парочки Java IDE не могу никак забить 8 ГБ памяти ничем нормальным. Все приложения были запущены не потому что мне надо было их использовать одновременно, а потому что я уже запускал все что мог ради теста. И что? Ничего, все практически влезло в 8GB RAM/zRAM. Так где эти кодеры что память не экономят? Та же Java имеет четкие и понятные причины использования такого количества памяти - арены сборщика мусора.

«RAM extenders» for MS-DOS

Хочется спросить, кто может гарантировать, что сам код zram не попадет в сжатый своп с красочными последствиями?

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

а вот если его нет, то зависнет

Честно говоря, не пробовал жить без свопа. Нынче какой в этом смысл?
Но вызов OOM Killer по-прежнему актуален и в такой конфигурации. По хорошему, он должен был быть вызван автоматически.

Да с таким количеством памяти даже 400 вкладок в фаерфоксе не открыть.

Пока ты херней маешься, я тут на тачке с 128 гиг оперативы отказался от SSD для кода:)

История успеха (комментарий)

Мой поинт в том что я не могу придумать нафига мне память

купи, ёпта

Привет, Ктулху.

Кстати да, список правильно оформи

Поздно

Мой поинт в том что я не могу придумать нафига мне память

Код в память влезет?

Не влезет

http://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/

Но изначальный эксперимент был на домашней тачке

Я когда-то выносил профиль ФФ на рамдиск с загрузкой/отгрузкой на старте/стопе системы. Работало ок.

У меня / - SSD, /home - HDD. Могу симлинки просто пробросить на SSD на самые горячие каталоги

Могу симлинки просто пробросить на SSD на самые горячие каталоги

Костыль. Лучше кеширование.

// 32 гига

Шестнадцати хватает на всё, лол.

Так сжимается только та память, которая уже ушла в swap?

У самого 8GB, чем забить - не понятно. Больше 2GB редко бывает. KDE.

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

Вчера 27 из 32 было занято.

16гиг только под VM.

Жесть! Потребности у тебя, конечно…

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

Разумеется, мне это тоже кажется, однако на практике все далеко не так.

Где гарантия что линукс не форматирует твой жесткий диск сейчас?

Я посмотрел - пока не форматирует.