Само приползло

[Andrew Shahoff]

http://www.ixbt.com/storage/gigabyte-iram-p1.shtml

[YellowMan]

Один мой коллега и приятель из метрополии уже много лет пользует в своих базах устройства собранные из обычной памяти и видимые системой как жесткий диск.
Объемомами около 100-200 Гб и ценой...лучше тут не писать

Только я название не помню - какое-то пингвинье

[Andrew Shahoff]

А такую можна на средней бизесьти сервачок засунуть , жаль правда на самом деле не SATAII

[YellowMan]

Можно - но на самом деле 4 Гб не так уж и много. По крайней мере для сервера БД, богатого памятью, выигрыш будет очень незначителен.

Хотя...я бы на такую штуку tempdb положил - была бы песня.

[rojer]

никаких отдельных железок не нужно, есть mfs / tmpfs.
не у всех, правда... :)

[YellowMan]

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

[Andrew Shahoff]

Это всётаки не совсем железка для больших серваков.
Вот у меня Халтурные серваки в Латвии живут на i815 и 1Гхз П3. Торчит там по гигу памяти ( большинствро мелких серваков и сегодня суппортят ап ту 4гига). Живут на них вэбы с небольшими базульками. Иногда у кустомеров случаються перформанс проблемы связанные с дусковой подсистемой , и я думаю переносом части статического контента и по возможности тэмп файлов на такое чудо избавило бы меня от коекаких головных болей и не надобылобы менять серваки.
Плюс на воркстэйшене моём можно былобы засунуть на такой диск тэмпы от фотошопа и премиера или ваше винду с него бутить. Ведь даже на моём дуалкоре бла бла бла тока 4 гига разместится могут (2 уже стоят и CS2 их лихо подъедает как с RAW фотками воркать начинаеш)

[rojer]

yellow man, да?
значит пихать какую-то непонятную железку с медленным (sata) доступом ты будешь, а доткнуть в сервер памяти и сделать в нём быстрый ram disk - нет?
так бросаться людьми - пробросаешься :)

[Andrew Shahoff]

рамдиск в оперативной памяти это извращение полное и в этом я с Жёлтым на 300% согласен. А железку такую как я уже писал можно сувать там где оперативка не экспандится больше. Конечно , если есть возможность добавить 4 гига в сервак к оперативке , то такая железка не нужна (кроме случая инстала на неё самой операционки). Но если возможности нет ?

[YellowMan]

Плюс на воркстэйшене моём можно былобы засунуть на такой диск тэмпы от фотошопа и премиера или ваше винду с него бутить.

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

Для твоих серверов я бы сказал что самое лучшее что ты можешь сделать - положить туда MySQL аналог tempdb. Или сами базы, если маленькие.

yellow man, да?
значит пихать какую-то непонятную железку с медленным (sata) доступом ты будешь, а доткнуть в сервер памяти и сделать в нём быстрый ram disk - нет?

Да, именно так - а знаешь почему ? Просто у непонятной железки есть БАТАРЕЙКА. А у диска в памяти ее нет.

[rojer]

на это я могу сказать, что хранить даже на батарейке что-либо важное - самоубийство (специально посмотрел: время хранения по расчётам ixbt - 18-29 часов, при этом они рекомендуют не закладываться больше чем на 10-12).
всё равно ты будешь (должен) регулярно бэкапить то что там есть на хдд, иначе... иначе лучше тебе успеть уволиться по собственному желанию, прежде чем сервер останется без света на продолжительное время :)
продолжаем логическую цепочку. если всё равно бэкапить содержимое, то не всё ли равно, со странного ли девайса, либо с tmpfs? правильно, абс. всё равно. в итоге, тебе всё равно потребуется схема бэкап-рестора.

я использую tmpfs на mysql-серверах - для хранения темповых таблиц. понятное дело, тут бекапить нечего.
ещё я использую tmpfs размером 256 мб для хранения байесовских баз на антиспам-фильтре. сделано это для максимального ускорения доступа и снижения lock contention. можно хранить байесовские базы в sql, с теми же результатми, но я считаю что моё решение оптимально - максимальная простота (не нужно держать целую rdbms для такой мелкой базы) + почти нулевой простой в локах за счёт использования tmpfs (когда .db-шки лежали на хдд, эффективная параллельная работа нескольких spamd была практически невозможна). базы ежедневно бэкапятся, при загрузке до запуска фильтра производится рестор из последнего дампа. таким образом перезагрузка равносильна откату к ночным базам, что абс. не критично, т.к. поддерживаются они всё равно на автомате.
как тебе такое решение? можно идти в отдел кадров писать заявление?

[YellowMan]

Значит по пунктам

продолжаем логическую цепочку. если всё равно бэкапить содержимое, то не всё ли равно, со странного ли девайса, либо с tmpfs? правильно, абс. всё равно. в итоге, тебе всё равно потребуется схема бэкап-рестора.

Не правильно, не все равно. Попробуй написать план обычного и аварийного бекапа/восстановления для обоих случаев и ты сразу увидишь разницу.

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

Это конкретная проблема конкретного МуСкуля. Если он так плохо работает с памятью что выгоднее держать диск в памяти вместо того чтобы просто отдать свободную память МуСкулю то тогда да, такое решение вполне практично.
Обычно для коммерческих баз выделить больше памяти серверу оказываеться гораздо эффективнее, тем более что большинство операций с tempdb они и так держат в памяти.

ещё я использую tmpfs размером 256 мб для хранения байесовских баз на антиспам-фильтре. сделано это для максимального ускорения доступа и снижения lock contention. можно хранить байесовские базы в sql, с теми же результатми, но я считаю что моё решение оптимально - максимальная простота (не нужно держать целую rdbms для такой мелкой базы) + почти нулевой простой в локах за счёт использования tmpfs (когда .db-шки лежали на хдд, эффективная параллельная работа нескольких spamd была практически невозможна). базы ежедневно бэкапятся, при загрузке до запуска фильтра производится рестор из последнего дампа. таким образом перезагрузка равносильна откату к ночным базам, что абс. не критично, т.к. поддерживаются они всё равно на автомате.
как тебе такое решение? можно идти в отдел кадров писать заявление?

Опять же - если ты можешь себе позволить в любой момент откатиться до последнего бекапа (и тебе все равно сколько времени это займет) - держи на здоровье. Только не называй это сервером

почти нулевой простой в локах за счёт использования tmpfs (когда .db-шки лежали на хдд, эффективная параллельная работа нескольких spamd была практически невозможна).

Вот это интересно - это из-за того что диски медленные или из-за того что приложение написано "свободным сообществом профессионалов-энтузиастов в свободное от работы время" (с) ? Что-же писатели не предусмотрели параллельную работу ? Или у них в требованиях есть диск в памяти ?

максимальная простота (не нужно держать целую rdbms для такой мелкой базы)

Что значит - держать целую РДБМС ? Это же не тигр в банке, ее кормить не надо. Нормально спроектированная база будет на порядки быстрее файловой системы - в том числе и за счет более оптимального использования памяти, которую ты сейчас занял файлами....

[rojer]

Сообщение от YellowMan

Не правильно, не все равно. Попробуй написать план обычного и аварийного бекапа/восстановления для обоих случаев и ты сразу увидишь разницу.

я не вижу разницы. тебе так и так нужно делать копирование инфы с этого диска на стабильный носитель.
пока ты пишешь планы, я пишу скрипт, который автоматом бэкапит и ресторит всё что мне нужно :)

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

Это конкретная проблема конкретного МуСкуля. Если он так плохо работает с памятью что выгоднее держать диск в памяти вместо того чтобы просто отдать свободную память МуСкулю то тогда да, такое решение вполне практично.
Обычно для коммерческих баз выделить больше памяти серверу оказываеться гораздо эффективнее, тем более что большинство операций с tempdb они и так держат в памяти.

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

Опять же - если ты можешь себе позволить в любой момент откатиться до последнего бекапа (и тебе все равно сколько времени это займет) - держи на здоровье. Только не называй это сервером :)

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

Вот это интересно - это из-за того что диски медленные или из-за того что приложение написано "свободным сообществом профессионалов-энтузиастов в свободное от работы время" (с) ? Что-же писатели не предусмотрели параллельную работу ? Или у них в требованиях есть диск в памяти ?

требования нет. хранить в дб-файлах проще, но медленнее. у нас большой почтовый трафик и сравнительно большие байесовские базы.
в этом случае есть вариант перейти на другой бэкенд их хранения - мускуль, постгрес... я вот пошёл другим путём. оценил ситуацию и вместо того чтобы взводить дополнительную софтину или гонять этот бесполезный трафик по сети и снижать надёжность, я просто перенёс байесовские .db в tmpfs.
т.к. включён autolearn, то большое количество проходящего спама вызывает запись в базу токенов. на дисках оно подтормаживает из-за многочисленных операций fsync(), требующих чтобы блок при записи лёг на диск. всё это время дбфайл эксклюзивно залочен.

Что значит - держать целую РДБМС ? Это же не тигр в банке, ее кормить не надо. Нормально спроектированная база будет на порядки быстрее файловой системы - в том числе и за счет более оптимального использования памяти, которую ты сейчас занял файлами....

для этих целей оказывается избыточным ставить и держать отдельную софтину, когда можно обойтись встроенной поддержкой db_file и встроенной же (в ос) поддержкой такой штуки как фс в памяти.
дополнительно пишется только небольшая обвязка по бекап-рестору и запихивается в крон. всё.
по поводу занятой памяти - не надо. память не выделяется под фс жёстко, а только по мере надобности. причём часть тмпфс может высвопляться наравне с другой памятью. речь, максимум, может идти только о неэффективном использовании файлового кэша, засоряющегося данными с тмпфс и не приносящего пользы. я думаю, что такая очевидная оптимизация (не кешировать данные с тмпфс) была сделана, хотя утверждать не могу.

[YellowMan]

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

Я просто долго думал какое еще приложение я знаю которое могло бы так работать и вспомнил только пару очень узко специализированных вещей - ну да ладно.

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

[abg]

Сообщение от YellowMan

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

Я просто долго думал какое еще приложение я знаю которое могло бы так работать и вспомнил только пару очень узко специализированных вещей - ну да ладно.

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

хм. а покажите мне батенька операционную систему и файловую систему, в которой есть возможность параллельной записи в файл.

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