Упражнения с бревном - 2 (graid5 + gjournal)

Не удержался и попробовал комбинацию из geom_raid5 + gjournal.

Пробовались варианты:

  • Журнал на отдельном диске (старый WD Raptor 36Gb, скорость линейной записи около 60 MB/sec)
  • Журнал на том же массиве, что и файловая система (RAID5 из 750GB дисков Western Digital)

Как ни странно, но результаты практически одинаковые, по всей видимости full stroke seek но бОльшая скорость линейного I/O удачно разменялись на обратные величины.

  • Скорость линейной записи большого файла: 41 MB/sec с журналом в конце массива и 44 MB/sec с журналом на отдельном диске. По iostat прекрасно видно как флашится журнал...
  • Скорость создания большого числа мелких файлов тоже практически одинакова: tar xzvf ports.tgz (порты от 7.1-RC1) занимает 33 секунды с журналом на массиве и 31 секунду с журналом на отдельном диске (файловая система смонтирована, как велено в мане, без soft-updates, но с -o async)
  • Для сравнения: распаковка того же ports.tgz на массиве без журнала занимает
    • 29 секунд при монтировании -o async (без soft-updates)
    • 2 минуты 13 секунд без async, но с soft-updates
  • Скорость чтения практически не поменялась, все цифры в пределах ошибки от предыдущих тестов.

Мораль совершенно понятна: для приложений с большим количеством мелких файловых операций журнал дает возможность безопасно включить async mount, но при этом безобразно портит скорость записи. Наверное, если вынести журнал на массивчик из мелких (но быстрых) SAS-дисков, то станет полегче.

Comments

"Для сравнения: распаковка того же ports.tgz на массиве без журнала занимает
29 секунд при монтировании -o async"
но "без -о..."?

Без soft-updates (естественно).

Дописал. Спасибо.

Вот тут и нужны карты с ценой в $x000 с парой гигов battarey-backed RAM.

Кстати, если уж упиратся в SAS, то можно взять просто Gigabyte i-RAM. Оно выдаёт почти полную SATA-I скорость и пережывает перезагрузку.

Перезагрузка - не проблема (давненько я не видал настоящий сервер, ушедший в панику).

Проблема - power loss часиков на 4-8.

Тогда UPS дешевле. Который успеет предупредить а корерктно погасить сервер.

Один из прецедентов пропадания питания у нас был - КЗ в блоке питания одного из серверов, естественно UPS погасил все, что в него было воткнуто.

По отдельному UPS-у на сервер - удорожает размещение очень существенно. Не знаю что там с надежностью будет, мелкие UPS-ы не должны быть особо надежными.

Да и потом, в датацентрах же и так UPS-ы с резервированием (чтобы при регламентных работах все работало) и они это все сделают лучше, чем клиенты (ну, во всяком случае должны). Просто железа много, вероятности умножаются.

Правильно, конечно, просто разбрасывать железо по разным ДЦ, чтобы при полном выходе из строя одного (двух?) мощности на нормальное функционирование хватало, но мы пока недостаточно крупный для этого потребитель.

2 секунды -- это безобразно портит?

40 мегабайт в секунду против 120 (на линейной записи) - это безобразно портит.

А 29 - покажите мне человека, который будет async делать на файловой системе в пару терабайт....

я что, читать не умею?

==
Мораль совершенно понятна: для приложений с <b>большим количеством мелких файловых операций</b> журнал дает возможность безопасно включить async mount, но при этом <b>безобразно портит скорость записи</b>.
==

==
Скорость создания большого числа мелких файлов тоже практически одинакова: tar xzvf ports.tgz (порты от 7.1-RC1) занимает 33 секунды с журналом на массиве и 31 секунду с журналом на отдельном диске
==

==
Для сравнения: распаковка того же ports.tgz на массиве без журнала занимает 29 секунд при монтировании -o async (без soft-updates)
==

<q>А 29 - покажите мне человека, который будет async делать на файловой системе в пару терабайт....</q>
я буду

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

Следи за руками
mount -o async volume /mnt - 29 сек
mount -o async volume.journal /mnt - 31 сек
mount volume /mnt 2:13

Если ты готов монтировать первым способом и тебе не страшно - журнал тебе не нужен (если не хочется выиграть на bgfsck)

готов, не страшно
bgfsck -- глюк и зло

Вот если вынести журнал на <a href="http://www.nix.ru/autocatalog/ramdisk/Gigabyte_iRAM_GCRAMDISKGB1_4xDDRSA...этот</a> девайс, будет интереснее

А сколько он живет без питания?

Другими словами, в нормальный датацентр - можно ставить, а во всякие жопы вроде Курчатника (где если сервер сломался вечером пятницы - попадешь к нему только во вторник) - лучше не.

В Курчатник, конечно, лучше вообще не, но жизнь - сложная штука.

Но 16 часов - это интересно, дома можно попробовать. Жалко что туда только 4 гига можно положить.

4 гига ты туда надорвёшься ставить -- там же DDR, а не DDR2. Она же дорогая уже как чёрт знает что.

У меня все ходы записаны!

Если туда подходит регистровая-ECC память, то этого добра я наковыряю по старым дохлым серверам (скорее всего, 4 гигабайта просто дома найдется)

Но вообще, типа вот: http://www.dostavka.ru/product_id/5666782
25 баксов за гигабайт. Всего будет, соответственно 160+4*25 = 260.

Хотя, конечно, если место и SATA-порты лишние есть, то 3x36GB Wd raptor получаются не дороже. И, соответственно, план: на сами рапторы ставим систему, на хвостах (началах) - делаем stripe для лога.

Дурдом.

Регистровая? Нет конечно. Это же СОВСЕМ другая память. Много ли ты знаешь устройст, где можноставить и регистровую и обычную? Вот обычная ECC, скорее всего, пойдёт, без использования ECC.

i-RAM и рамбокс в его нынешней имплементации суть кал, т.к. sata-1, обычный ddr убивают наглухо всю радость от идеи. На доставке, кстати, не надо ничего сейчас покупать, почему - могу мылом обьяснить.
А сделать i-RAM на ddr2, я так полагаю, не дают либо ограничения на standby power у ATX-питальников, либо какие-то другие экзистенциальные проблемы, т.к. они вроде бы пробовали и даже что-то показывали, но в серию это не пошло.

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

А так - все б-м понятно и просто надо ждать, пока SSD подешевеют еще в пару раз. Быстрый диск - это хорошо, но 4 гигабайта оного - безобразно мало.

Правда с SSD все тоже интересно - чую я, что нас ждет SATA-3 в самом ближайшем будущем, ибо засатурейтить 3 гигабита уже несложно совсем.

я уже с этой штукой 2 года живу, и писал тебе об этом
у меня там скратч файл шопа живёт
к сожалению только SATA-1 - вроде как ничто не машало сделать и SATA-2 и чип поддерживает
и всё такое, но как-то мимо твикеров эта железка прошла
http://images.people.overclockers.ru/101921.gif

я тут прикольную фичу в ЦС4 нашел, а может багу
открываем 2 копии одной картинки
в первой делаем автоконтраст
во второй сначала переводим в 32 бита потом автоконтраст и назад в 16 бит
http://ai.kuz.ru/cs4/cs4_16_32_ac.jpg

вопрос: почему так картинки отличаются?

В датацерт _это_ ставить? Мда... и много сервер до сих пор идут с PCI слотами?

Хочеться RAM SSD для сервера то вот это нужно ставить http://www.superssd.com/products_sub.htm

Есть же разные задачи.

Вот в 'penny sort' не выигрывают никогда очень дорогие решения. А выигрывают (по количеству гигабайт отсортированных "за 1 цент") очень даже дешевые. И практика (гугловая, да!) показывает, что оно еще и масштабируется (ценой припахивания к этому стад сисадминов, но несмотря на это цена решения получается разумной).

Согласен, для различных рынков продукт нужно предлагать адекватный.

Кстати Алекс вот такой вопрос к тебе и к сообществу - я знаю что рабочая OS для тебя это линук или фриска, но признаемся что больше половины серверов (если не больше) для среднестатистичской компании - это винды. А сервера для корпоративных нужд - file sharing/print там почти 100% винды.

Так вот если ты CIO такой компании заинтересовало бы тебе решение, которое вируализирует неспользуемое пространство на всех этих сетевых серверах так что админам не придется создавать nn различных file shares на -дцати различных серверах, пасти их (следить за permission/utilization на каждом из них) а вместо это это решение предлагает один, уриверсальный интерфейс через которого можно создавать file shares а софт автоматически определяет где и как оно будет хранится.

При этом решение чисто софтверное, не требует укладки оптики, установки софта на всех северах и при этом предлагет data redundancy - если один или даже несколько серверов упадут, то данные не будет потеряны.

Видишь ли, я не CIO такой компании. И компания у нас не среднестатистическая.

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

А если у нее 100 терабайт, то важна не только прозрачность, но и перформанс.

Если нужно 100TB то тогда замешаны совершенно другие деньги.

Насчет performance - если десктопы подключаются на 100 мегабит, то performance там вторично. Даже если если гигабит везде, то обычно народ не перекачивает 100 гиговые файлы через сеть. Обычно им нужно открыть/закрыть/скопировать MS Office файл через сеть. Для этого тоже не нужно performance, иначе народ не создавал сети на виндах которые охватывают два континента.

А у которых нет 100Tb - те не заплатят за решение больше, чем 400 баксов за два терабайтных диска.

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

Кстати, а попробовать raid5 в gvinum не хочешь? :)

Ну у меня там уже терабайт рабочих файлов лежит.

Я могу их обратно списать на WS, но это целый день.

Ничего уже не хочу :)

Да, это аргумент :)