|
| 1.2, гость (?), 14:29, 21/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based md-устройствами.
| | |
| |
| 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, видимо.
Эх, надо было сразу уточнить.
Про запись речь, не про чтение. Чтоб если файл потрогали два раза за полминуты с интенсивным обменом -- то долетело, и то может быть не сразу, последнее состояние на момент простоя. А не залипли после того, как первое решило синкнуться, почувствовав странички грязными.
| | |
|
|
|
| |
| 2.4, airman (?), 14:51, 21/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Элементарно, Ватсон, выделяем свободные 2 гига озу под временные таблицы Mysql.
| | |
| |
| 3.7, pavlinux (ok), 14:57, 21/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Так для этого, и ниже сказанного не нужно периодически сваливать на диск...
если таблицы, при отрубе питания, испортит, то их восстанавливать не имеет смысла.
Под гей-сервер тем более, обычного RAM диска хватит...
| | |
| |
| |
| |
| |
| Часть нити удалена модератором |
| 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-диске - ускоряло да. И даже между перезагрузками выживало, пока эту недокументированную фичу не поломали.
| | |
|
|
| 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.23, Аноним (23), 05:23, 22/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Думаю можно применять для хранения баз 1с.
Да и еще применений придумать можно...
| | |
| |
| 2.24, Ne01eX (??), 07:18, 24/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Если Ramback можно использовать и как обычный рамдиск без средств синхронизации с тем же самым увеличением производительности по сравнению с Ram-диском в 25 раз, то это уже само по себе ценное достижение. Рамдиск как рамдиск широко используется в Live-системах (RTK GNU/Linux, например ;-)). Маршрутизаторы, опять же. Да много где. Даже на обычном дестопе многие дистрибутивные ядра, до монтирования основной корневой ФС подгружают необходимые модули с рамдиска. Так что, думаю, в скором времени фишка под названием Ramback войдет в майнлайн ядра.
| | |
|
|
