Daniel Phillips представил (http://lwn.net/Articles/272534/) начальную реализацию виртуального устройства Ramback, представляющего собой RAM-диск снабженный средствами синхронизации данных на жесткий диск. При тестировании нового устройства, было зафиксировано увеличение производительности примерно в 25 раз, при гарантированной сохранности информации в случае перезагрузки (после загрузки задумано автоматическое восстановление содержимого Ramback-диска).
К сожалению, высокая производительность имеет свою цену - Ramback не рассчитан на обработку ситуации экстренного пропадания питания в случае сбоя, он лишь помечает в реальном режиме времени измененные области данных, далее периодически запускается процесс сбрасывающий изменения на диск. В случае если до сброса изменений произойдет сбой - данные будут потеряны и для восстановления целостности Ramback-диска понадобиться выполнение fsck.
Кроме того, Christoph Lameter предложил (http://groups.google.com/group/fa.linux.kernel/msg/0a7...URL: http://www.linuxworld.com/news/2008/031808-kernel.html
Новость: http://www.opennet.me/opennews/art.shtml?num=14845
Для ноутов самое то!
Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based md-устройствами.
+ gjournal сверху
>Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based md-устройствами.Политика зеркалирования там подкручивается? Тут это как раз важно.
>>Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based md-устройствами.
>
>Политика зеркалирования там подкручивается? Тут это как раз важно.Из man gmirror:
-b balance Specifies balance algorithm to use, one of:
load Read from the component with the
lowest load.prefer Read from the component with the
biggest priority.round-robin Use round-robin algorithm when
choosing component to read.split Split read requests, which are big-
ger than or equal to slice size on N
pieces, where N is the number of
active components. This is the
default balance algorithm.Нужен prefer, видимо.
>>>Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based
>>>md-устройствами.
>>Политика зеркалирования там подкручивается? Тут это как раз важно.
>Из man gmirror: [...]
>Нужен prefer, видимо.Эх, надо было сразу уточнить.
Про запись речь, не про чтение. Чтоб если файл потрогали два раза за полминуты с интенсивным обменом -- то долетело, и то может быть не сразу, последнее состояние на момент простоя. А не залипли после того, как первое решило синкнуться, почувствовав странички грязными.
А зачем?
Пытаюсь придумать применение....
Какие будут предложения?
Элементарно, Ватсон, выделяем свободные 2 гига озу под временные таблицы Mysql.
Так для этого, и ниже сказанного не нужно периодически сваливать на диск...
если таблицы, при отрубе питания, испортит, то их восстанавливать не имеет смысла.Под гей-сервер тем более, обычного RAM диска хватит...
Упс! s/ГЕЙ/ГЕЙМ :)
>>привет от доктора Фрейда :D
>
>Это ты Logitech_у передай, пущай клавы делают нормальные...Да уж новомодные клавы это Ж*** просто, кнопка "повер" под "делетом" вообще какой-то извращенец придумал разместить, я вот себе еще лет десяток назад раздобыл брендовую межделмашевскую клаву, которой уже тогда лет 10 было, внушаить... пару кило весом, никаких лишних кнопок. :) Ни на какое мультимедийное фуфло не сменяю.
Все равно "чистый" рам диск получается хлопотней, даже под левелоперские БД, в базе ведь полно хранимок, триггеров, далеко не вся логика пишется на клиенте/сервере_приложений, дохрена логики можно в саму БД запихать, сочинял-сочинял какую-нидь хитроумную хранимку, иные по нескольку дней ковырять приходится... если оно резко потеряется будет жалко, даже девелоперскую.
Думаю, примерно то же, что у tmpfs, только с требованием сохранения данных между загрузками.Например, пакеты или исошки в памяти собирать сильно веселей, поскольку то, что должно бы писаться на диск из грязного кэша -- до диска обычно не долетает за ненадобностью.
>Думаю, примерно то же, что у tmpfs, только с требованием сохранения данных
>между загрузками.
>
>Например, пакеты или исошки в памяти собирать сильно веселей, поскольку то, что
>должно бы писаться на диск из грязного кэша -- до диска
>обычно не долетает за ненадобностью.В fido7.ru.unix.bsd делал такое для /usr/obj на swap-backed md-диске - ускоряло да. И даже между перезагрузками выживало, пока эту недокументированную фичу не поломали.
Во мы лохи....
Цэ есть ничто иное как реклама этого девайса - http://www.violin-memory.com/products/violin1010.html
Идеально подойдет под игровой сервер, чтоб держать базы, например, файрберда для девелоперов, если базулька весом гигов до 4-х. Чтоб на сказевом рэйде сэкономить. Под продакшн я бы не решился БД на таком "диске" держать. Да еще подойдет опять же по БД например кубы считать, транзакции ведет нормальный сервак, а кубы считает для аналитики на чем-то подобном.
Вобщем куда применить придумать можно. :)
Второй патч, более интересный, но закрадываются сомнения...> для уменьшения влияния фрагментации памяти
> при выделении больших непрерывных блоков.1. Проблема фрагментации обычно возникает как раз на большом кол-ве, но маленьких malloc_ов.
2. А если не удастся выделить непрерывную область виртуальной памяти.
>Второй патч, более интересный, но закрадываются сомнения...
>1. Проблема фрагментации обычно возникает как раз на большом кол-ве, но маленьких
>malloc_ов.Тут про выделение заведомо известно, что оно короткоживущее -- соответственно возможно решать другую задачу (иначе).
>2. А если не удастся выделить непрерывную область виртуальной памяти.
Берётся из отложенного в нижней.
Лучше на LWN читать: http://lwn.net/Articles/272693/ (A better DMA memory allocator) и http://lwn.net/Articles/273030/ (How to use a terabyte of RAM)
ram disk активно пытаются у нас внедрить разработчики для разработки - исходники на ЖД, а результаты компиляции в память
>ram disk активно пытаются у нас внедрить разработчики для разработки - исходники
>на ЖД, а результаты компиляции в памятьПро ccache они не в курсе часом? ~/.ccache/ можно организовать [симлинком] на отдельный tmpfs уже сегодня.
> Про ccache они не в курсе часом? ~/.ccache/ можно организовать [симлинком] на
> отдельный tmpfs уже сегодня.А почему не в переменную окружения? Неужели опрос симлинка выходит дешевле опроса переменной окружения?
Кладем базу на рамдиск и асинхронно реплицирует на жесткий
Сразу вспомнился ZX Spectrum, RAM DOS я впервые там увидел :)
Думаю можно применять для хранения баз 1с.Да и еще применений придумать можно...
Если Ramback можно использовать и как обычный рамдиск без средств синхронизации с тем же самым увеличением производительности по сравнению с Ram-диском в 25 раз, то это уже само по себе ценное достижение. Рамдиск как рамдиск широко используется в Live-системах (RTK GNU/Linux, например ;-)). Маршрутизаторы, опять же. Да много где. Даже на обычном дестопе многие дистрибутивные ядра, до монтирования основной корневой ФС подгружают необходимые модули с рамдиска. Так что, думаю, в скором времени фишка под названием Ramback войдет в майнлайн ядра.