LINUX.ORG.RU

Возможно ли объеденить RAM и SSD в 1 диск?

 , , ,


1

1

К примеру у меня есть 256GB RAM, и например 512GB SSD диск.

Есть ли возможность получить диск ну скажем на 200GB RAM + 512GB SSD?

В идеале сначала чтобы использовалась RAM, а если не хватает места, то пишет на SSD.

Надежность хранения само собой неважна. Нужно вот такое временное хранилище.

Самое главное, чтобы итоговое хранилище по размеру было суммой RAM (например куска в 200GB) и SSD.

Погуглил немного нашел проект mergefs. Наверное вариант tmpfs + mergefs мне подойдет.

Поделитесь вашими соображениями ))

Создай в рам в тмпфс файл размером 200 Гб, потом из этого файла и устройства ssd создай либо raid 0

Либо группу томов lvm.

anonymous
()

А зачем вам такие скорости? Я бы посмотрел в сторону lvm, там можно делать из нескольких PV один раздел.

einhander ★★★★★
()

А почему нет? Попробовать выделить блочное устройство zram и каким нибудь софтовым рейд-массивом прикрутить к ssd. Только я ноль в рейд-массивах, слышал только что всякие btrfs и прочие умеют располагаться на нескольких блочных устройствах.

А, точно. Извиняюсь. tmpfs, которая свопится на ssd будет иметь похожие характеристики. Хотя сам процесс свопинга не слишком эффективный по цпу, было бы неплохо вынести балансировку память/диск этого массива кому нибудь другому.

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

overlayfs+tmpfs

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

Ну использование памяти как блочное устройство и работать там с файлами на ФС тоже по процессору будет не эффективно. Может задержки будут даже больше чем у nvme.

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

задержки будут даже больше чем у nvme

ты чё-то подупоролся

anonymous
()

tmpfs, по описанию, умеет сбрасывать лишнее в swap раздел/файл. Я не видел такого её использования в реальности, но такой подход, на мой взляд будет быстрее чем любые ФС прокинутые через FUSE (mergefs в их числе) и менее костыльнее чем любые варианты raid’ов/lvm.

Ещё из плюсов tmpfs – она не юзает page cache, в отличии от обычных файловых систем, а значит в оперативке не будет лишних копирований информации.

В теории есть вариант с создание в оперативке pmem устройства и форматированием в ФС с поддержкой DAX (опять же чтобы не делать лишнее копирование данных в оперативке). В теории это позволит выиграть в производительности, но абсолютно не понятно как такую ФС объединять с ФС на SSD так чтобы было не костыльно и быстро.

TL;DR

Создай большой swap раздел/файл на SSD (в размер того, сколько ты хочешь использовать места) . Подключи его как системный SWAP. Создай tmpfs раздел на размер того, сколько ты хочешь отдать оперативки + swap. попробуй запустить что-то что требует много оперативки и заполнить tmpfs данными сверх свободной оперативки хотябы в 2 раза. По идее система должна активно свопить данные и не вызывать OOM у запущенного приложения которому нужно много оперативки

chaos_dremel ★★
()
Последнее исправление: chaos_dremel (всего исправлений: 2)
Ответ на: комментарий от system-root

Задержки при работе с блочным устройством в памяти будут наносекундными.

Но если это zram с бедленным алгоритмом сжатия, тогда да, будет медленное сжатие. Но ведь алгоритм указывается для каждого отдельного устройства. И там были какие то неэффективные, но ПЦ реактивные. А ещё блы какой то несжатый ram-диск.

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

Я не видел такого её использования в реальности, но такой подход, на мой взляд будет быстрее чем любые ФС прокинутые через…

Я использую этот подход в реальности. Меня в принципе такая конфигурация устраивает из за простоты и моих невысоких требований по обмену данными, но на самом деле она медленная.

Дело не в самой tmpfs, она действительно быстрей любой fs. Дело в однопоточной подсистеме свопа, которая делает кучу лишних действий, но при этом совершенно не предназначена для оптимизации размещения файлов между оперативкой и диском. И ещё на подсистему свопа линукса жалуются что она медлительна. Я согласен, у меня 1 ядро цпу RPi3 может пережевать не больше 10-15 Мб/сек обмена данными с своп-ssd. т.е. всё упирается далеко не в скорость диска.

Поэтому я и предполагаю, что если некий софтовый рэйд-массив типа btrfs, zfs или lvm умеет балансировать данные между устройствами с разной скоростью, то он справится куда лучше связки tmpfs+swap. Но вообще тесты нужны. Они кстати не сложные, если освоить настройку этих самых софтовых рэйдов.

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

У тебя есть тесты, где рандомное чтение с 100-200 гигов файла в памяти будет наносекундным? У меня все серваки теперь на винде, проверять в vm не хочется.

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

Ну свопинг как раз можно тюнить. У топикстартера совершенно другие объёмы памяти, и поэтому даже дефолтные настройки watermark_scale_factor будут сбрасывать данные в swap большими кусками с почти линейной записью, что крайне положительно будет сказываться на общей производительности.

P.S. Вы, кстати, не пробовали тюнинговать этот параметр на RPi3? А то дефолтные настройки на 1Гиге оперативки дают около 1 метра сбрасывания в своп за раз

chaos_dremel ★★
()
Ответ на: комментарий от system-root

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

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

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

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

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

Просто в nvme каждое ядро может послать запрос, а каналов памяти ограниченно, плюс сторадж отдаст ровно столько, сколько попросили, а память отдаст весь чанк из которого ещё вытащить нужные данные какое-то количество циклов потратить нужно.

Я то сам никогда не тестил, мало ли.

system-root ★★★★★
()

Легко решается на FreeBSD

tmpfs (RAM) + SWAP в ZVOL на ZFS.

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

А разве независимо от каналов и ядер данные с диска не должны сначала лечь в оперативку, а потом быть прочитны оттуда собственно кодом на цпу? Ну и что страничное обращение к оперативке, что блочное к дискам. По слухам диски сейчас физически тоже по 4Кб хранят.

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

Но ведь механизм DMA, т.е. когда диск пишет в оперативку без прямого участия цпу. Или он пишет сразу в кеш цпу? В любом случае, это не для большого i/o.

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

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

anonymous
()

tmpfs не позволит тебе ограничить размер фс на уровне фс т.е. если тебе надо из 256гб выделить 250 то ты должен сам ограничивать запись ибо если ты зашлешь в неё 256 то они все … влезут, но рам кончится при этом.
В твоём случае, в идеале, разделить запись программно на уровне писальщика

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

очень интересная идея, а для tmpfs сложно ограничить объем, после которого она начинает лезть на SSD?

я так понимаю параметр swap и указывает лезть в своп

mount -F tmpfs [-o size=number] swap mount-point

не получится ли так, что весь велосипед будет медленнее чем LVM, из-за того, что не будет доступен быстрый RAM, сожрется все под tmpfs

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

очень интересная идея, а для tmpfs сложно ограничить объем, после которого она начинает лезть на SSD?

как минимум cgoups можно приложению указать лимит memory.high в т.ч. на tmpfs влияет вроде бы, но чет не то все равно

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

Для драматичности я сжульничаю и упрощу.

Сейчас я пишу с ноутбука на скайлейке с DDR3L-1600, где пропускная способность 12.8Gbps, а рядом у меня стоит десктоп с 960 Evo со скоростью последовательного чтения 3.3Gbps. Если драматизировтаь ещё сильнее, мы возьмём 980 PRO с последовательным чтением уже на 7Gbps, и будем сравнивать это в лоб.

Это бред. Но, тем не менее, даже если бы SSD стали быстрее RAM, твоё утверждение всё равно не верно.

от оперативки бы уже отказались в пользу nvme

SSD — расходник, расчитанный на 300-600 циклов перезапили, а рама почти вечная.

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

Вопрос:

В идеале сначала чтобы использовалась RAM, а если не хватает места, то пишет на SSD.

Возможный ответ, хотя и не совсем то:

ARC - это кэш ZFS, расположенный в оперативной памяти, L2ARC - его продолжение (Layer 2, второй уровень), но на более медленном, чем оперативная память носителе (но при этом обладающим бОльшим объемом) и в то же время, более быстром, чем диски самого массива. Обычно, в роли носителей для L2ARC используются SSD диски, так как их скорости чтения/записи с легкостью превосходят последние модели SAS.

Если таы вместо кеширующего SSD поставишь устройство ZRAM то будет примерно то, что ты хотел.
Причём надо учитывать то, что ZFS не единственная система которая так умеет и так же то, что после ребута весь ZFS пул часть кеша которого пропадёт скоре всего превратится в труху.

В целом то что ты описываешь по описанию более всего напоминает LLVM когда несколько разделов на разных накопителях объёдиняются в один LLVM раздел.

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

качок не знает разницы между latency(измеряется в наносекундах) ?

для памяти это 20ns, для ssd 25000ns. ты обосрался в 1250 раз

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

разницы между latency и bandwidth…

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

другие цифры говорят о 7.82ns для памяти и «few microseconds» для nvme, если взять 7.82 и 7820 - один хрен разница 1000 раз

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

mount -F tmpfs [-o size=number] swap mount-point

Тут swap это не параметр, а лейбл или типа того. Параметра отвечающего за использование свопа там нет

Из хороших новостей, в ядре 5.8 завезли swappines до 200, как раз на случай быстрых устройств со свопом. Но это скорее всего поможет только от выгрузки инодов и файлового кеша из оперативки. От выгрузки памяти программ поможет только то, что к памяти программ обращений обычно больше и там больше вариантов сказать системе «этот кусок памяти очень важен»

Ещё есть вариант, если программа которой нужна оперативка, поддерживает huge pages (postgresql, например), то можно при старте системы отдать часть оперативки под эти самые huge pages и тем самым обеспечить программе гарантированный от посягательств свопинга пул оперативки:

Pages that are used as huge pages are reserved inside the kernel and cannot be used for other purposes. Huge pages cannot be swapped out under memory pressure

Отсюда: https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

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

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

И не будь это анонизмус настолько феерически тупым, он бы уловил поинт в конце.

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

Где тег chia?

Если это оно то дефицит видеокарт и SSD не самое плохое из того, что нас ждёт в будущем.
Майнеры тянут руки к серверным платам и ОЗУ!

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

SSD — расходник, расчитанный на 300-600 циклов перезапили

*вздох* нет, слава богу, только игрушечные.

Вон есть у меня серваки, рождающие и убивающие короткоживущие виртуалки не реже, чем раз в десять секунд. Виртуалок гигов 500 и перегенерируются они в большинстве своем раз в два часа. В твоём мире я бы покупал 1ТБ RAM. В моем достаточно обычного SSD за $100-$150 и ниче, живёт.

Очевидно же, что речь не о QLC.

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

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

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

Видел я всё, дурачок. Поинт был в конце, а в начале я по фану посравнивал ужа с ежом и прямо от этом написал. Просто у какой-то анонимной чукчи сегодня ПМС.

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

ssd используют вместо «вечных» hdd, так что тут ты тоже обосрался. будь они быстрее оперативки, их бы использовали как быстрый кэш для неё вроде как bcache работает, и просто бы периодически меняли по мере деградации

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

если ты всё видел, значит ты либо не знаешь разницы между latency и bandwidth, либо намеренно выставил себя дураком. разницы по сути нет

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

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

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

А зачем вам такие скорости?

Это чёртов майнер на дисках (монета «чиа»). Из-за таких, как ТС HDD подорожали до 30000. Цуки!

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

Я не написал ни слова про скорость доступа и не сравнивал её с пропускной способностью. Протрезвей, перечитай. Я просто в очередной раз переоценил собеседника, не подумав, что общаюсь с беспросветным дебилом, который на белом глазу зацепится за толстый вброс. Который прямым текстом подписан «это бред».

И ладно бы ты просто вброс не понял, будучи отбитым Шелдоном. Но нет же, ты и не одупляешь, что доступ доступом, а ведь данные ещё прочитать нужно.

Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD
Read 1 MB sequentially from memory 250,000 ns 250 us
Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory

https://gist.github.com/jboner/2841832

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

еще был такой прикольный вариант http://vixdevelop.blogspot.com/2016/09/zraid.html - объединение tmpfs и hdd в raid1 для совмещения скорости ram и энергонезависимости hdd :) явно не твой случай, но так для обзорности.

вместо mergefs я бы таки порекомендовал aufs - в ней можно указать последовательность заполнения склеиваемых фс, т.е. чтобы первой заполнялось tmpfs, а уж при заполнении tmpfs записывалось в ssd

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

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

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

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

Ещё раз, для особенно тупых: поинт был в конце. Вечная рама, убиваемый за сутки SSD.

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

на это тоже был ответ:

ssd используют вместо «вечных» hdd, так что тут ты тоже обосрался. будь они быстрее оперативки, их бы использовали как быстрый кэш для неё вроде как bcache работает, и просто бы периодически меняли по мере деградации

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

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

И на твой бестолковый ответ был ответ.

Ладно, раз уж начали.

прочитать не будет времени, оно будет тратиться на доступ

L3 у нас урки в тёмном переулке отжали?

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

кэш маленький и бесполезен при постоянных кэш-миссах. можешь загрузится с mem=64MB и отписаться cюда, как тебе L3 помогает при сваппинге, лол

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.