tmpfs

Смотри в сторону https://slitaz.org/en/
И в сторону https://github.com/sp00f1ng/booty
booty 2.0 beta

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

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

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

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

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

overlayfs+tmpfs

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

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

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

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

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

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

TL;DR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не, pci же напрямую в процессор идёт. Ну по крайней мере если воткнуть nvme в такую линию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос:

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

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

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

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

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

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

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

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

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

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

Где тег chia?

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

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

Где тег chia?

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

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

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

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

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

Ненужно, есть дисковый кеш и SSD на 512.

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

980 PRO MZ-V8P1T0BW (1TB)

Warranty

5 Years or 600 TBW

Смирись.

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

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

Манечка, не нервничай ты так. Уже что-то совсем невпопад пишешь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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