Вопрос по РЕЙДУ на 3Ware (AMCC)

А больше и не получишь. Только тут такой расклад - купил бы карточку на sil3114, и получил бы те же самые 4 порта, 120Mb/s на raid5, только на полштуки дешевле ;)

Страйп сделай равным кратным размеру предвыборки на чтение у винта (обычно 128к), мелкий страйп просадит производительность на работе с мелким файлом.

а 64К ето разве мелкий ?

Странно почему на сайте 3Варе и везде в описании к етой карточке написано 400 Мб\сек ? хотя теоритически на 4 х винтах максимум что можно выжать ето 240 = по 60 каждый х 4.... хм. чтож делать... как его разогнать до скорости равной выложеных за него денег :-)

> а 64К ето разве мелкий ?

Мелкий конечно. Ну поставь 4к, если охота понять суть эффекта.

> Странно почему на сайте 3Варе и везде в описании к етой карточке написано 400 Мб\сек ?

Поди ещё мелкософта сайт почитай, там тоже много чего написано, и о мега производительности и всё такое - только не написаны характеристики суперкампутера, который для достижения оной требуется. Лимит ПСП шины контроллера знаешь? Вот больше не и получишь.

> хотя теоритически на 4 х винтах максимум что можно выжать ето 240 = по 60 каждый х 4....

Угу, на raid0 в безлунную ночь после принесения в жертву цифровым богам 13-и девственниц. А в софтрейде линуксовом такое достигается даже без безлунной ночи.

> хм. чтож делать... как его разогнать до скорости равной выложеных за него денег :-)

Сначала думают, потом покупают. Я тоже хотел 12 портовый купить на PCI-X/PCI-E, а потом оказалось что софтовый даёт такую же скорость, а проц отнюдь не напрягается обсчётом XOR'ов, а полторы штуки денег можно запросто пропить или потратить на мощный ящик, где эти 12 винтов будут жить без малейшего напряга и доскомфорта.

Интересно можно ли в 3варе изменить размер страйпа без потери данных в режиме онлайн, мож кто знает...

> Лимит ПСП шины контроллера знаешь? Вот больше не и получишь. PCI-X 133 вобщето гораздо больше 400 мб\сек. А там имено эта шина и мамка серверная с pci-x 133

> Сначала думают, потом покупают. В силу решения задач нужен имено хардовый рейд, стоял Адаптек 2610 он выдавал на рейд-10 всего 90-100 Мб\сек на чтение. в редй-5 - 60... вот заменили на более крутой 3варе. То что 3варе для сата рейда самое лутшее тут спору нет ето подтверждается и инфой по гуглу и наградами 3варе но вот то что они пишут не правду про скорость ето конечно плохо...

И еще подскажите какой утилитой проверить скорость записи в линуксе?

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

Я же говорю, для SATA рейд 5 действует примерное эмпирическое правило - скорость растёт не линейно с добавлением винтов, а от х1 на каждую пару винтов. То есть на твоих 4 наблюдаем правильную картину.

Хочешь скорости - делай 1+0 или чистый 0, но никак не 5-й со столь маленьким количеством шпинделей. Говорят самые хорошие вообще не 3-варь, а Арека, да к тому же та на той же аппаратной базе содержит в прошивке код для raid6, а может и путаю с чем.

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

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

Ну-ну.

> И еще подскажите какой утилитой проверить скорость записи в линуксе?

вообще есть пакеты для тестирования дисковой подсистемы, например bonnie ++ , но если по простому, то

time cp /100mb-file.bin /mnt/hda1/

где /mnt/hda1 путь по которому примонтирован первый раздел диска hda. разделив потом 100mb на количество секунд выданных тебе time, получишь скорость в mb/sec .

параллельно можно смотреть 'iostat 1' который будет тебе показывать тоже количество блоков прошедших через дисковую систему в единицу (1) времени.

Здравствуйте, вообще-то RAID-контроллеры затачивают не под потоковые, а под случайные чтение/запись. Так что Ваш тест мало пользы принесет. А вообще стандартный тест - iometer. Причем максимальную производительность можно получить на нескольких десятков потоков.

To Garhik

Извините, но Вы, видимо, совершенно не владеете информацией по RAIDам. 3Ware - один из лучших SATA-RAID-контроллеров, более-менее на равных с ними могут конкурировать только Areca. И, поверьте, она стоит своих денег. Потому как скорость для RAIDа - далеко не первый параметр, главное - надежность, наличие штатных средств восстановления массива при сбое и серьезные средства мониторинга. Та же 3Ware, например, автоматически при загрузке поднимает в on-line вылетевшие в результате сбоя питания диски. А вот что Вы будете делать в такой ситуации на контроллере от SiliconImage - это большой вопрос :).

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

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

С уважением, Сергей.

> To Garhik

Даже начали с ошибочки :) Вы случайно не в "крупном интеграторе" работаете?

> Извините, но Вы, видимо, совершенно не владеете информацией по RAIDам.

Смотрим:

> 3Ware - один из лучших SATA-RAID-контроллеров, более-менее на равных с ними могут конкурировать только Areca. И, поверьте, она стоит своих денег.

Арека была помянута, будем спорить дальше? :)

> Потому как скорость для RAIDа - далеко не первый параметр, главное - надежность,

Отсутствие лишних деталей и костыльной избыточности в цепи даёт по любому "+" к надёжности. Проблемы силиконов - это проблемы силиконов, вместо дифференциации на "галимый ширпотреб" и "карточки для реальных пацанов а мегабаксы" давно уже пора делать надёжные "контроллеры" строго по стардарту, а не комбайны "всё в одном". Всё остальное сделает OS - и к тому же избавимся от потенциальных глюков в фирмварях, избирательной несовместимости, и прочих радостей проприетарных технологий.

> наличие штатных средств восстановления массива при сбое и серьезные средства мониторинга.

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

> Та же 3Ware, например, автоматически при загрузке поднимает в on-line вылетевшие в результате сбоя питания диски. А вот что Вы будете делать в такой ситуации на контроллере от SiliconImage - это большой вопрос :).

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

В чём правда, брат? ;)

> Даже начали с ошибочки :)

Пошу прощения! Честное слово, не специально :(.

> Вы случайно не в "крупном интеграторе" работаете?

Случайно, нет :). Хотя ход Вашей логики для меня остался непонятным :(.

> Арека была помянута, будем спорить дальше? :)

?? А я разве с этим спорил? Насколько я помню, Вами было высказано утверждение, что SiliconImage ничуть не хуже контроллеров от 3Ware и Areca. Вот c ним я и не согласился :).

> Отсутствие лишних деталей и костыльной избыточности в цепи даёт по любому "+" к надёжности. Проблемы силиконов - это проблемы силиконов, вместо дифференциации на "галимый ширпотреб" и "карточки для реальных пацанов а мегабаксы" давно уже пора делать надёжные "контроллеры" строго по стардарту, а не комбайны "всё в одном". Всё остальное сделает OS - и к тому же избавимся от потенциальных глюков в фирмварях, избирательной несовместимости, и прочих радостей проприетарных технологий.

Даже не знаю, что сказать :). Вы действительно считаете, что связка CPU - RAM - OS проще устроена, чем примитивный процессор контроллера, заточенный всего на несколько родственных задач и firmware, занимающая 2-3 Mb вместо 40 Mb архивов ядра OS?

А деление на "ширпотреб" и "карточки для реальных пацанов" - оно не маркетинговое. Посмотрите статистику развалов RAIDов и Вам все станет ясно. По поводу "комбайна" - это именно Вы предлагаете его устроить из системы. У CPU есть свои функции, почему бы не отдать расчет XOR специализированному устройству, специально под это заточенному? А вот по поводу "проприетарных технологий" полностью Вас поддерживаю. Только решать эту проблему надо не затаскиванием всего и вся в ядро, а открытием соответствующих firmware.

> Всё включено, смарт работает, мыло кому нужно шлётся, и т.п.

Это, конечно, все очень здорово. А вот что с этим всем будет при проблемах с системой? Кстати, как Вы думаете, что будет с производительностью Вашего программного RAID при серьезной загрузке процессора?

> В таком случае самые классные контроллеры стоят на готовых серверах - из-за, к примеру, хьюлеттовского ай-ло, что в сочетании с линуксом позволяет вообще не переплачивать за непойми что ;)

?? Я не очень понял, что имеется ввиду? ILo ействительно классная штука (кстати, такого рода функционал есть и у других производителей (ISM у Intel, IPMI у Supermicro), только какое это отношение имеет к RAID-контроллерам? IMHO, одно другое не заменяет. Да и еще, какая связь у ILo с Linux? Я сам с HP не работал, но мне всегда казалось, что ILo - OS-независимая система мониторинга и управления сервером. Я не прав?

> Продолжать работать, новые силиконы действуют точно так же :)

Спасибо за информацию. Честно говоря, не знал :(.

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

Не очень понял - избыточность относительно чего? Базу данных на 20 Gb с несколькими десятками пользователей Вы тоже на программный RAID посадите? По поводу ценообразования - в курсе. Но мы вроде о деньгах и не говорили, или я что-то пропустил?

> В чём правда, брат? ;)

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

С уважением, Сергей.

> Случайно, нет :). Хотя ход Вашей логики для меня остался непонятным :(.

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

> ?? А я разве с этим спорил? Насколько я помню, Вами было высказано утверждение, что SiliconImage ничуть не хуже контроллеров от 3Ware и Areca. Вот c ним я и не согласился :).

Скажу больше - были модели начального уровня от Адаптеков, где использовались без зазрения совести те же sil-3132 парами, причём сия комбинация легко стоила в N раз дороже полностью аналогичного решения от какого-нибудь вендора второго эшелона. Да, конечно, "тестирование", "надёжность", всё такое - но в данной ситуации разницу в надёжности можно свалить только на качество пайки :)

> Даже не знаю, что сказать :). Вы действительно считаете, что связка CPU - RAM - OS проще устроена, чем примитивный процессор контроллера, заточенный всего на несколько родственных задач и firmware, занимающая 2-3 Mb вместо 40 Mb архивов ядра OS?

Конечно!!! Вместо "контроллера" будет просто лишний трафик по SATA-линкам (в случае избыточности). Фишка в том, что за этот примитивизм хотят слишком много денег. И в подтверждение:

darkstar ~ # du -csbl /lib/modules/2.6.21/kernel/drivers/md/* 125936 /lib/modules/2.6.21/kernel/drivers/md/md-mod.ko 12744 /lib/modules/2.6.21/kernel/drivers/md/raid0.ko 34776 /lib/modules/2.6.21/kernel/drivers/md/raid10.ko 35136 /lib/modules/2.6.21/kernel/drivers/md/raid1.ko 142944 /lib/modules/2.6.21/kernel/drivers/md/raid456.ko 9048 /lib/modules/2.6.21/kernel/drivers/md/xor.ko

И где тут "40Мб"? :) Фирмварь контроллера отдыхает! К тому же стоит учесть байки про иной раз имеющие место быть несовместимости с определёнными моделями винтов, подо что расходуется драгоценное место в фирмвари и возникает зависимость от расторопности спецов вендора.

> А деление на "ширпотреб" и "карточки для реальных пацанов" - оно не маркетинговое. Посмотрите статистику развалов RAIDов и Вам все станет ясно. По поводу "комбайна" - это именно Вы предлагаете его устроить из системы. У CPU есть свои функции, почему бы не отдать расчет XOR специализированному устройству, специально под это заточенному? А вот по поводу "проприетарных технологий" полностью Вас поддерживаю. Только решать эту проблему надо не затаскиванием всего и вся в ядро, а открытием соответствующих firmware.

Или так, и тогда выяснится, что в фирмвари прошит тот же линукс :) Опыты показывают, что скорость счёта XOR'ов на ЦПУ ограничены лишь ПСП RAM, в особенности при задействовании SSE-блоков, что на современных процессорах мощны неимоверно - ~6.7Gb/s на стареньком оптероне ещё с DDR-1 памятью, побольше на Conroe, а новые модели от AMD обещают вообще порвать всё и вся. Думаю, что лишний процессор и удвоение памяти за цену контроллера лишними никогда не будут.

> Это, конечно, все очень здорово. А вот что с этим всем будет при проблемах с системой? Кстати, как Вы думаете, что будет с производительностью Вашего программного RAID при серьезной загрузке процессора?

По уму - нужно брать и тестировать. Но логика подсказывает, что те 5-10% загрузки на ввод-вывод __одного__ процессора уходящие на 8-12 винтов легко перекроются лишним процом.

> ?? Я не очень понял, что имеется ввиду? ILo ействительно классная штука (кстати, такого рода функционал есть и у других производителей (ISM у Intel, IPMI у Supermicro), только какое это отношение имеет к RAID-контроллерам? IMHO, одно другое не заменяет. Да и еще, какая связь у ILo с Linux? Я сам с HP не работал, но мне всегда казалось, что ILo - OS-независимая система мониторинга и управления сервером. Я не прав?

Именно что классная. Исторически сложилось так, что я работал именно с HP. Смысл такой - выкинуть из чипа функции рейд-контроллера, кэш, посадить на PCI-E и использовать линуксовый софт-рейд, а iLO или аналоги - как систему мониторинга всей этой шарманки, благо он практически независим от прочей системы.

> Спасибо за информацию. Честно говоря, не знал :(.

Даже на древних sil-3114 (четырёхпортовые, SATA-1) патчами привели ситуацию к такому виду, что сбой питания или сбой на SATA-линке не считается за реальный сбой, просто передёргивается линк и работа идёт дальше. В том и прелесть открытых технологий.

> Не очень понял - избыточность относительно чего? Базу данных на 20 Gb с несколькими десятками пользователей Вы тоже на программный RAID посадите? По поводу ценообразования - в курсе. Но мы вроде о деньгах и не говорили, или я что-то пропустил?

Местный гуру и знатный шаман Dimez говорил, что рейды 0, 1 и 0+1 на софтрейде рвут аппаратные, с коими и были проблемы. Человек сие уважаемый, фигню не порет, звёзд много - почему бы и не поверить? :)

> Хороший вопрос :). IMHO, в адекватности выбираемых программно-аппаратных средств решаемой задаче :). А то мы с Вами можем долго обсуждать, кто сильнее - кит, или слон :)).

Это да :)

// форматирование

darkstar ~ # du -csbl /lib/modules/2.6.21/kernel/drivers/md/*
125936  /lib/modules/2.6.21/kernel/drivers/md/md-mod.ko
12744   /lib/modules/2.6.21/kernel/drivers/md/raid0.ko
34776   /lib/modules/2.6.21/kernel/drivers/md/raid10.ko
35136   /lib/modules/2.6.21/kernel/drivers/md/raid1.ko
142944  /lib/modules/2.6.21/kernel/drivers/md/raid456.ko
9048    /lib/modules/2.6.21/kernel/drivers/md/xor.ko

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

> Смысл такой - выкинуть из чипа функции рейд-контроллера, кэш, посадить на PCI-E и использовать линуксовый софт-рейд, а iLO или аналоги - как систему мониторинга всей этой шарманки, благо он практически независим от прочей системы.

Так а какой тогда смысл в iLO? Основная прелесть этой технологии именно в ее OS-независимости. А в указанном Вами случае можно использовать стандартные возможности OS, т. к. если система накроется, то никакой мониторинг программному RAID уже не поможет :(.

> скорость счёта XOR'ов на ЦПУ ограничены ПСП RAM

Кстати, да. Особенно это актуально для новых 4-ядерных Xeon'ов - у них и так серьезный затык по ПСП RAM :(.

> По уму - нужно брать и тестировать. Но логика подсказывает, что те 5-10% загрузки на ввод-вывод __одного__ процессора уходящие на 8-12 винтов легко перекроются лишним процом.

Тут не так все просто. Во-первых, рост нагрузки не линеен. Во-вторых, забивание ПСП RAM и шины скажется на всех CPUs. В-третьих, если вернуться к стоимости, Вы представляете разницу в цене двух- и четырехпроцессорных систем? На этом фоне аппаратный контроллер стоит копейки :).

> Местный гуру и знатный шаман Dimez говорил, что рейды 0, 1 и 0+1 на софтрейде рвут аппаратные, с коими и были проблемы. Человек сие уважаемый, фигню не порет, звёзд много - почему бы и не поверить? :)

Нисколько не сомневаюсь в компетентности Dimez :). Тем не менее, это зависит от того, что и как мерить. Программные RAIDы будут лучше на потоковых операциях (и то только на не загруженной машине). Но обычно требуются IOPs, и вот тут программный RAID проиграет :(.

C уважением, Сергей.

Закончилась миграция на 256К страйп, скорость по hdparm -t /dev/sda1 упала с 130 до 55 мб\сек :-(.... хочется поехать в офис 3Варе и запхнуть эту карту комута поглубже... а она еще и с BBU ... так что мало не покажется... Итог: возвращаю старый страйп в 64К, чтоб хоть 130 выжать... Потестю ёё на количество IO\s может хоть там порадует, ведь действительно, главное ИО и поточность например 100 мб\сек в 5 потоков ето будет не плохо :-), к томуже 100 Мб\сек это почти полностью загруженый гигабитный езернет, этого должно хватить при условии отличной работы карты в многопточном режиме, все таки ведь кеш в 128Мб должен чтото делать....

> Даже не знаю, что сказать :). Вы действительно считаете, что связка CPU - RAM - OS проще устроена, чем примитивный процессор контроллера, заточенный всего на несколько родственных задач и firmware, занимающая 2-3 Mb вместо 40 Mb архивов ядра OS?

Хренасе. Полноценный 300-МГц ARM у Areca + 256Mb RAM + Ethernet + web-server крутящийся внутри этой железки. Это полноценная ARM-машина.

> Я не очень понял, что имеется ввиду? ILo ействительно классная штука (кстати, такого рода функционал есть и у других производителей (ISM у Intel, IPMI у Supermicro),

IMPI -- это стандарт. iLO -- Это название реализации. Не надо путать.

> Так а какой тогда смысл в iLO? Основная прелесть этой технологии именно в ее OS-независимости. А в указанном Вами случае можно использовать стандартные возможности OS, т. к. если система накроется, то никакой мониторинг программному RAID уже не поможет :(.

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

> Кстати, да. Особенно это актуально для новых 4-ядерных Xeon'ов - у них и так серьезный затык по ПСП RAM :(.

Отсюда и простое следствие - что Оптероны таки да рулят ;)

> Тут не так все просто. Во-первых, рост нагрузки не линеен. Во-вторых, забивание ПСП RAM и шины скажется на всех CPUs. В-третьих, если вернуться к стоимости, Вы представляете разницу в цене двух- и четырехпроцессорных систем? На этом фоне аппаратный контроллер стоит копейки :).

Конечно представляю. Эта разница равна разности в стоимости между двумя 1- и 2-ядерными процессорами :) Ну а поскольку на подходе 4-ядерные, то сим можно вообще не заморачиваться, базам ПСП RAM не сильно надобна, лишь бы количество её было близким к числу "дофигища", NUMA-системам ограниченность интеловских систем по ПСП контроллера памяти до одного места, так что всё в порядке.

> Нисколько не сомневаюсь в компетентности Dimez :). Тем не менее, это зависит от того, что и как мерить. Программные RAIDы будут лучше на потоковых операциях (и то только на не загруженной машине). Но обычно требуются IOPs, и вот тут программный RAID проиграет :(.

Смысл в том, что теоретический максимум для железа программно не перешагнуть, а значит с ростом IOPS нагрузка на xor-модуль расти не будет - просто может возникнуть ситуация, когда DB сожрёт все процессоры (разные люди запросы пишут, ага :( ), сервер встанет колом, loadavg устремится в бесконечность - но и на железном контроллере в такой ситуации большого IOPS'а не получить.

Здравствуйте,

> Хренасе. Полноценный 300-МГц ARM у Areca + 256Mb RAM + Ethernet + web-server крутящийся внутри этой железки. Это полноценная ARM-машина.

Я с этим и не спорю :). Но, надеюсь, Вы согласитесь, что это гораздо проще, чем современная x86-машина?

> IPMI -- это стандарт. iLO -- Это название реализации. Не надо путать.

Согласен, но в случае Supermicro это еще и название реализации.

To Gharik

> Только вот софт-рейды можно свободно переносить между любыми контроллерами, а в случае железных контроллеров такой лафы никто не обещает.

Честно говоря, довольно сомнительное преимущество. Вылет контроллера - чрезвычайно редкая ситуация, в этом случае вполне можно потратить какое-то время на восстановление из backup'а. Да и в 99% случаев COD совместим в линейке контроллеров одного производителя.

> Эта разница равна разности в стоимости между двумя 1- и 2-ядерными процессорами :)

Мне кажется, Вы прекрасно поняли, о чем речь :).

> NUMA-системам ограниченность интеловских систем по ПСП контроллера памяти до одного места, так что всё в порядке.

С памятью да, а вот как быть с шиной?

> Отсюда и простое следствие - что Оптероны таки да рулят ;)

Есть одна проблема - пока их просто нет (имеются ввиду 4-х ядерные процессоры) :(.

> Смысл в том, что теоретический максимум для железа программно не перешагнуть, а значит с ростом IOPS нагрузка на xor-модуль расти не будет

Не очень понял, что имеется ввиду, особенно вторую часть. Число IOPs, который способен отдать контроллер, зависит в первую очередь от его процессора, а во вторую - от кривости firmware :). Естественно, это верно при наличии достаточного числа дисков. Кроме того, наличие write back- кэша может в определенных условиях дать очень существенный выигрыш по IOPs.

> Честно говоря, довольно сомнительное преимущество. Вылет контроллера - чрезвычайно редкая ситуация, в этом случае вполне можно потратить какое-то время на восстановление из backup'а. Да и в 99% случаев COD совместим в линейке контроллеров одного производителя.

О да, а железная необходимость держать на складе каждой твари по паре, а то и по пять штук - есть, вероятно, весьма весомый довод в пользу аппаратных контроллеров, ага? :)

> Мне кажется, Вы прекрасно поняли, о чем речь :).

АМД вот заверяет, что будущие 4х-ядерники встант на 1207-е сокеты, куда раньше только двухядерники вставали. Что с учётом ещё и микроархитектурных улучшений задвинет необходимость покупать специальную 4-сокетную платформу в тёмный лес.

> С памятью да, а вот как быть с шиной?

Вам мало Hypertransopt 2/3? o.0 - даже 8( )

> Есть одна проблема - пока их просто нет (имеются ввиду 4-х ядерные процессоры) :(.

Базу для последующего апгрейда закупить можно уже почти год как. Может и больше даже. АМД не Интель, раз сказала "будет 1207 ножек и они подойдут Агене, на крайняк биос перепрошить придётся, добавив PID'ы новые" - значит так и будет.

> Не очень понял, что имеется ввиду, особенно вторую часть. Число IOPs, который способен отдать контроллер, зависит в первую очередь от его процессора, а во вторую - от кривости firmware :).

Кошерных программистов-ядерщиков кривость какой-то там "фирмвари" не волнует, в том и плюс. Процессора хватит на всё, чай не во времена мохнатых лесных кодеров и жёстких дисков с гидроприводом живём :)

> Естественно, это верно при наличии достаточного числа дисков. Кроме того, наличие write back- кэша может в определенных условиях дать очень существенный выигрыш по IOPs.

И вдобавок - часто поминаемый "дополнительный трафик по шине" на самом деле не так уж велик, для платформы АМД выигрыш за счёт NUMA+Hypertransport перекрывает его на раз. По поводу кэша - из цепочки убираются все лишние ступени, кэширование в N-местах и прочие плохие вещи, кэш один - системная память, которой реально __много__ и она реально __быстрая__. Фактически имеем прямую дорожку из памяти на диски.

Впрочем всё это такая фигня в сравнении с ядерной войной...

> О да, а железная необходимость держать на складе каждой твари по паре, а то и по пять штук - есть, вероятно, весьма весомый довод в пользу аппаратных контроллеров, ага? :)

Может, стоит просто выбирать нормальных поставщиков и пользоваться их складом? Вот Вы специалист по HP, Вам тоже приходится держать свой запас комплектующих на складе? Т. е. все их carepack'и т. п. - миф?

> АМД вот заверяет, что будущие 4х-ядерники встант на 1207-е сокеты, куда раньше только двухядерники вставали. Что с учётом ещё и микроархитектурных улучшений задвинет необходимость покупать специальную 4-сокетную платформу в тёмный лес.

Да Вы оптимист :). Впрочем, всякое может быть, но я как-то давно перестал верить подобным заявлениям вендоров :(.

> Процессора хватит на всё, чай не во времена мохнатых лесных кодеров и жёстких дисков с гидроприводом живём :)

Не знаю. В чем-то Вы правы, но идея выноса специализированных однотипных расчетов на отдельные процессоры мне кажется более привлекательной. Все-таки, согласитесь, задачи растут никак не медленнее прогресса в железе, так что CPU без работы не сидит. И еще один момент. Firmware контроллеров, помимо реализации основных алгоритмов RAID, занимается еще и оптимизацией очереди запросов к дискам. В ряде случаев это дает потрясающий эффект, особенно на SATA-дисках, у которых традиционно с этим проблемы. Ну и потом, следуя Вашей логике, нужно отказаться от графических ускорителей в картах, железных модемов и т. п. - пусть работает CPU. Только вот кто при таком подходе будет задачи пользователя обсчитывать? :).

> И вдобавок - часто поминаемый "дополнительный трафик по шине" на самом деле не так уж велик, для платформы АМД выигрыш за счёт NUMA+Hypertransport перекрывает его на раз. По поводу кэша - из цепочки убираются все лишние ступени, кэширование в N-местах и прочие плохие вещи, кэш один - системная память, которой реально __много__ и она реально __быстрая__. Фактически имеем прямую дорожку из памяти на диски.

Не буду спорить - не специалист в железе. Один только вопрос - Вы уверены, что SATA-порты на современных платах напрямую к Hypertransport-link'ам подключены? А по поводу кэширования в RAM - это намного менее эффективно, хотя бы из-за конкуренции сдругими процессами. Ну и еще раз - в случае контроллера это не просто тупое кэширование, а управление очередью запросов. Для SATA-дисков, лишенных нормальной своей очереди - незаменимая вещь.

С уважением, Сергей.

> Может, стоит просто выбирать нормальных поставщиков и пользоваться их складом? Вот Вы специалист по HP, Вам тоже приходится держать свой запас комплектующих на складе? Т. е. все их carepack'и т. п. - миф?

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

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

> Да Вы оптимист :). Впрочем, всякое может быть, но я как-то давно перестал верить подобным заявлениям вендоров :(.

Реалист, ибо все всё равно умрём ;) S1207 - официальный серверный сокет от АМД на N ближайших лет, AM3 - десктопный,

> Не знаю. В чем-то Вы правы, но идея выноса специализированных однотипных расчетов на отдельные процессоры мне кажется более привлекательной.

Получаем систему, утыканную всяким буллшитом в итоге со слабым центральным процом, встающим колом на мало-мальски нетипичной задаче. Циски, э? :)

> Все-таки, согласитесь, задачи растут никак не медленнее прогресса в железе, так что CPU без работы не сидит.

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

> И еще один момент. Firmware контроллеров, помимо реализации основных алгоритмов RAID, занимается еще и оптимизацией очереди запросов к дискам. В ряде случаев это дает потрясающий эффект, особенно на SATA-дисках, у которых традиционно с этим проблемы.

+1. Только вот на SATA есть NCQ как штатная фича, которая тоже даёт немаленький эффект, особенно на мелких запросах. Да и вшить такой универсальный оптимизатор в ядро было бы гораздо эффективнее, чем каждый раз надеяться на контроллеры и к тому же дало бы эффект на всех классах HDD, независимо от интерфейса.

> Ну и потом, следуя Вашей логике, нужно отказаться от графических ускорителей в картах, железных модемов и т. п. - пусть работает CPU. Только вот кто при таком подходе будет задачи пользователя обсчитывать? :).

Это таки разные классы задач. XOR - вообще одна из базовых операций на любом процессоре, гонять под сие отдельные примочки было нужно в то время, когда ЦПУ были относительно медленными, а ксорить нужно было никак не меньше.

> Не буду спорить - не специалист в железе. Один только вопрос - Вы уверены, что SATA-порты на современных платах напрямую к Hypertransport-link'ам подключены?

На HT-линке висит чипсет, в котором и состоит SATA-контроллер, и вообще вся периферия, DMA в случае AMD - очень интересная штука. Так что фактически получается всяко короче, нежели HT-чипсет-(мост на PCI-64/X/E)-контроллер и только потом трафик улетает на винты.

> А по поводу кэширования в RAM - это намного менее эффективно, хотя бы из-за конкуренции сдругими процессами. Ну и еще раз - в случае контроллера это не просто тупое кэширование, а управление очередью запросов. Для SATA-дисков, лишенных нормальной своей очереди - незаменимая вещь.

А ядро линуксовое всегда кэширует информацию в памяти перед сбросом на диск, от сего не уйти. И забудьте наконец про "лишённые очереди диски" :) SATA-II с работающим NCQ творит чудеса, и производительность реально растёт - особенно на дико фрагментированной ФС сие заметно, как раз тот самый аналог больших IOPS, производительность поднимается кратно.

> И ждать сутки, пока с другого конца Москвы привезут сервер? Пробки московские не я придумывал, поэтому некий запасец по любому должен лежать на собственном складе.

Логично. Мне в этом плане проще - поставщик находится в 800 м :).

> Получаем систему, утыканную всяким буллшитом в итоге со слабым центральным процом, встающим колом на мало-мальски нетипичной задаче. Циски, э? :)

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

> На HT-линке висит чипсет, в котором и состоит SATA-контроллер, и вообще вся периферия, DMA в случае AMD - очень интересная штука.

Спасибо за разъяснения. Я почему-то считал, что SATA-контроллеры висят на PCI-express. А не подскажите заодно, как обстоит с этим дело в Intell'овских системах?

> И забудьте наконец про "лишённые очереди диски" :) SATA-II с работающим NCQ творит чудеса, и производительность реально растёт - особенно на дико фрагментированной ФС сие заметно, как раз тот самый аналог больших IOPS, производительность поднимается кратно.

А вот с этим категорически не согласен. NCQ - всего лишь жалкое подобие нормальной очереди в SCSI, FC, или SAS-винтах. Дело, как я понимаю, даже не в ограниченной длине очереди (32 против 256), а в самих алгоритмах. Недаром по IOPs'ам 10000 rpm SATA проигрывает аналогичному SCSI в 2.5-4 раза. Да и где Вы видели "кратный подъем производительности", обусловленный NCQ? Речь идет о единицах (даже не десятках) процентов.

С уважением, Сергей.