The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

RAM-диск, синхронизирующий данные на постоянный носитель, для Linux

21.03.2008 13:15

Daniel Phillips представил начальную реализацию виртуального устройства Ramback, представляющего собой RAM-диск снабженный средствами синхронизации данных на жесткий диск. При тестировании нового устройства, было зафиксировано увеличение производительности примерно в 25 раз, при гарантированной сохранности информации в случае перезагрузки (после загрузки задумано автоматическое восстановление содержимого Ramback-диска).

К сожалению, высокая производительность имеет свою цену - Ramback не рассчитан на обработку ситуации экстренного пропадания питания в случае сбоя, он лишь помечает в реальном режиме времени измененные области данных, далее периодически запускается процесс сбрасывающий изменения на диск. В случае если до сброса изменений произойдет сбой - данные будут потеряны и для восстановления целостности Ramback-диска понадобиться выполнение fsck.

Кроме того, Christoph Lameter предложил способ уменьшения влияния фрагментации памяти при выделении больших непрерывных блоков. Суть метода в том, что вначале предлагается попытаться выделить непрерывную область в физической памяти, и только если это не удалось - выделить непрерывную область виртуальной памяти.

  1. Главная ссылка к новости (http://www.linuxworld.com/news...)
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/14845-ramdisk
Ключевые слова: ramdisk, disk, cache, linux, patch, speed
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, vizor (ok), 14:11, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для ноутов самое то!
     
  • 1.2, гость (?), 14:29, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based md-устройствами.
     
     
  • 2.6, maksim (??), 14:55, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    + gjournal сверху
     
  • 2.19, Michael Shigorin (ok), 18:41, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based md-устройствами.

    Политика зеркалирования там подкручивается?  Тут это как раз важно.

     
     
  • 3.26, nuclight (ok), 15:29, 25/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Фо фре вообще элементарно делается 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, видимо.

     
     
  • 4.28, Michael Shigorin (ok), 01:11, 30/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based
    >>>md-устройствами.
    >>Политика зеркалирования там подкручивается?  Тут это как раз важно.
    >Из man gmirror: [...]
    >Нужен prefer, видимо.

    Эх, надо было сразу уточнить.

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

     

  • 1.3, pavlinux (ok), 14:31, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А зачем?
    Пытаюсь придумать применение....
    Какие будут предложения?

     
     
  • 2.4, airman (?), 14:51, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Элементарно, Ватсон, выделяем свободные 2 гига озу под временные таблицы Mysql.
     
     
  • 3.7, pavlinux (ok), 14:57, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Так для этого, и ниже сказанного не нужно периодически сваливать на диск...
    если таблицы, при отрубе питания, испортит, то их восстанавливать не имеет смысла.

    Под гей-сервер тем более, обычного RAM диска хватит...

     
     
  • 4.8, pavlinux (ok), 14:59, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Упс!  s/ГЕЙ/ГЕЙМ  :)
     
     
     
     
    Часть нити удалена модератором

  • 7.17, iv (?), 18:11, 21/03/2008 [ответить]  
  • +/
    >>привет от доктора Фрейда :D
    >
    >Это ты Logitech_у передай, пущай клавы делают нормальные...

    Да уж новомодные клавы это Ж*** просто, кнопка "повер" под "делетом" вообще какой-то извращенец придумал разместить, я вот себе еще лет десяток назад раздобыл брендовую межделмашевскую клаву, которой уже тогда лет 10 было, внушаить... пару кило весом, никаких лишних кнопок. :) Ни на какое мультимедийное фуфло не сменяю.

    Все равно "чистый" рам диск получается хлопотней, даже под левелоперские БД, в базе ведь полно хранимок, триггеров, далеко не вся логика пишется на клиенте/сервере_приложений, дохрена логики можно в саму БД запихать, сочинял-сочинял какую-нидь хитроумную хранимку, иные по нескольку дней ковырять приходится... если оно резко потеряется будет жалко, даже девелоперскую.

     
  • 2.18, Michael Shigorin (ok), 18:40, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю, примерно то же, что у tmpfs, только с требованием сохранения данных между загрузками.

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

     
     
  • 3.27, nuclight (ok), 15:38, 25/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Думаю, примерно то же, что у tmpfs, только с требованием сохранения данных
    >между загрузками.
    >
    >Например, пакеты или исошки в памяти собирать сильно веселей, поскольку то, что
    >должно бы писаться на диск из грязного кэша -- до диска
    >обычно не долетает за ненадобностью.

    В fido7.ru.unix.bsd делал такое для /usr/obj на swap-backed md-диске - ускоряло да. И даже между перезагрузками выживало, пока эту недокументированную фичу не поломали.

     
  • 2.20, pavlinux (ok), 18:42, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Во мы лохи....
    Цэ есть ничто иное как реклама этого девайса - http://www.violin-memory.com/products/violin1010.html

     

  • 1.5, Iv (??), 14:52, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Идеально подойдет под игровой сервер, чтоб держать базы, например, файрберда для девелоперов, если базулька весом гигов до 4-х. Чтоб на сказевом рэйде сэкономить. Под продакшн я бы не решился БД на таком "диске" держать. Да еще подойдет опять же по БД например кубы считать, транзакции ведет нормальный сервак, а кубы считает для аналитики на чем-то подобном.
    Вобщем куда применить придумать можно. :)
     
  • 1.9, pavlinux (ok), 15:04, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Второй патч, более интересный, но закрадываются сомнения...

    > для уменьшения влияния фрагментации памяти
    > при выделении больших непрерывных блоков.

    1. Проблема фрагментации обычно возникает как раз на большом кол-ве, но маленьких malloc_ов.

    2. А если не удастся выделить непрерывную область виртуальной памяти.



     
     
  • 2.21, Michael Shigorin (ok), 18:47, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Второй патч, более интересный, но закрадываются сомнения...
    >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)

     

  • 1.11, Аноним (11), 15:14, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ram disk активно пытаются у нас внедрить разработчики для разработки - исходники на ЖД, а результаты компиляции в память
     
     
  • 2.22, Michael Shigorin (ok), 18:48, 21/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >ram disk активно пытаются у нас внедрить разработчики для разработки - исходники
    >на ЖД, а результаты компиляции в память

    Про ccache они не в курсе часом? ~/.ccache/ можно организовать [симлинком] на отдельный tmpfs уже сегодня.

     
     
  • 3.25, Аноним (-), 14:13, 24/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Про ccache они не в курсе часом? ~/.ccache/ можно организовать [симлинком] на
    > отдельный tmpfs уже сегодня.

    А почему не в переменную окружения? Неужели опрос симлинка выходит дешевле опроса переменной окружения?

     

  • 1.13, Аноним (11), 15:53, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кладем базу на рамдиск и асинхронно реплицирует на жесткий
     
  • 1.14, Аноним (14), 16:25, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сразу вспомнился ZX Spectrum, RAM DOS я впервые там увидел :)
     
  • 1.23, Аноним (23), 05:23, 22/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Думаю можно применять для хранения баз 1с.

    Да и еще применений придумать можно...


     
     
  • 2.24, Ne01eX (??), 07:18, 24/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Если Ramback можно использовать и как обычный рамдиск без средств синхронизации с тем же самым увеличением производительности по сравнению с Ram-диском в 25 раз, то это уже само по себе ценное достижение. Рамдиск как рамдиск широко используется в Live-системах (RTK GNU/Linux, например ;-)). Маршрутизаторы, опять же. Да много где. Даже на обычном дестопе многие дистрибутивные ядра, до монтирования основной корневой ФС подгружают необходимые модули с рамдиска. Так что, думаю, в скором времени фишка под названием Ramback войдет в майнлайн ядра.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру