Opteron IO performance?

opteron + scsi U320 + hp-ux = write at 38Mb/s

Видишь как тебе хорошо :-)

Не уверен, что здесь виноват процессор. Может RAID или его драйвер?

> Не уверен, что здесь виноват процессор.

И я не уверен. Потому и спрашиваю!

> Может RAID или его драйвер?

Надеюсь.

Но почему-то тормоза наблюдаются на 3 независимых совершенно различных Оптеронах (4x Opteron, direct SCSI; 4x2 Opteron, Raid0 SCSI, 2x Opteron, Raid5 SATA).

а как там с выбором кэширования на самом контроллере?
write-back поддерживает?

насколько я знаю железные рейды способные дать 300 мб/сек - довольно большая редкость.

больше чем на 200-250 я думаю ращитывать не стоит.

мож конечно попробовать решения от DotHill они гарантировано позволяют получть более 500мб/с через двухканальный скази контроллер и за одно глянеш сколько такое удовольствие стоит

> а как там с выбором кэширования на самом контроллере? write-back поддерживает?

write-back дает порядка 5%. Мне же требуется 100-200 %

> больше чем на 200-250 я думаю ращитывать не стоит.

Дык, мне этого хватит...

а что за рейд?

а попробовать другой насколько проблематично будет?

мож драйвер подкрутить: типа очередь увеличить или какой нить мастер включить?

> а что за рейд?

MegaRaid 320-1

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

А где его узять?

>> а что за рейд?

>MegaRaid 320-1

насколько я помню эту железку то существенно больше ты с неё не получиш.

тоесть 100 - 120 по моей памяти гдето типичный предел. (хотя память может подвести)

там диски точно скази? мож внутрь sata напихано? тогда лучше и не жди ;-(

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

>А где его узять?

ну вы ж новое железо покупаете систематически?

так попросите у продавца на месяц или две недели

если в киеве то южстар наверное бы дала

> ...так попросите у продавца на месяц или две недели

Не, тут такое не канает... Германия, страна победившего бюрократизма!

>>MegaRaid 320-1

> насколько я помню эту железку то существенно больше ты с неё не получиш.

На их сайте пишут про 320 BM/s...

Только что связались с фирмой, что нам этот Оптерон впарила. Они тоже удивились столь низкой производительности и пообещали разобраться.

Оптерон не оптерон, но у меня на софтовом рейде из двух дисков на линейном чтении 110 Мб/c. amd64 2.2 ГГц

> на линейном чтении 110 Мб/c.

А запись?

оно PCI-X, должно быть? поддержка в ядре есть?
По поводу write-back - прирост должен быть больше %5 однозначно. Попробуй разные комбинации кэширования.
Попробуй спросить на 3nity.ru, По системе они подсказать мало что могут, а по железу могут просветить.

>На их сайте пишут про 320 BM/s...

хай не врут. это даже сказёвый шлейф не вытянет. если двухканальная система то конечно да а на одном канале 250 Мб/с ПОЛЕЗНЫХ данных - предел.

стоял год назад возле меня такой. плоховато помню. но что там никаких 320 и рядом не лежало - факт.

а попытатся дисков на 15К натыкать? мож попустит?

> оно PCI-X, должно быть?

Не-а, PCI

Но все равно должно хватать!

> По поводу write-back - прирост должен быть больше %5 однозначно.

Это если рандомные чтение-запись, как в базах данных.

Мне требуется линейная запись. При этом write-back тормозит; если выставить write-through, получается чуть быстрее.

> Попробуй разные комбинации кэширования.

Несколько дней игрались -- +/- 5-10%

> а попытатся дисков на 15К натыкать? мож попустит?

ВО-первых, где их узять?

Во-вторых -- вряд ли...

> Несколько дней игрались -- +/- 5-10%
пора возвращать продавцу )

x86_64 Dual Core AMD Opteron(tm) Processor 265
сата рейд на набордном MV88SX (сырой драйвер)
4G памяти

test # time dd if=/dev/zero of=FILE bs=1k count=102400
102400+0 records in
102400+0 records out

real 0m0.818s
user 0m0.012s
sys 0m0.776s
test # time dd if=/dev/zero of=FILE bs=1k count=1002400
1002400+0 records in
1002400+0 records out

real 0m12.240s
user 0m0.172s
sys 0m10.697s

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

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

причём IDE если у него только scsi?

Chubaka :

Немного не те объемы, попробуй раз в 100 побольше. А таким способом ты лишь тестируешь совместимость Линуксового IO решедуллера с кышом рейда.

Если есть хотя бы полтерабайта свободного на, скажем, /partition, попробуй, пожалуйста, такое:

time sh -c "dd if=/dev/zero of=/partition/garbage bs=1M count=500000; umount /partition"

Если меньше, пусть меньше, но обязательно с umount. Посто sync не поможет.

Все равно, 120 MB/s мне мало...

Кстати, проблема, похоже, потихоньку решается...

Позвонили фирмачи, сказали, что, действительно, комбинация PSI + один СКАЗИ канал + этот рейд большего не даст.

Обещают на днях прислать 2-канальный рейд контроллер на PSI-X

Кстати, при сравнении с Альтиксами я слегка лажанулся: на моих Альтиксах XVM вяжет как раз несколько СКАЗИ шин на PCI-X...

Одного не понимаю: зачем тогда все эти слова про Ultra-320, если оно более 100 не тянет?

на пол-тера не могу
порциями на пару десятков гигов могу.
что вывалить кэш можно добавить sync, но разница уж точно не в разы.
надо было сразу pci-x брать.
есть lsi u320 scsi на pci, но машины загружены, корректного теста не будет.
но вобщем "по ощущениям" могу сказать, что scsi массивы на pci работают медленне, чем саташные на pci-x

> что вывалить кэш можно добавить sync, но разница уж точно не в разы.

Уверяю, на гигабайтных объемах (при 4Гигах памяти) именно в разы!

И еще раз -- sync НЕ ПОМОЖЕТ!!! Нужен umount!

> ...но вобщем "по ощущениям" могу сказать, что scsi массивы на pci работают медленне, чем саташные на pci-x

Ну вот этого я совершенно не понимаю... Ограничения pci должны быть никак не меньше 400 MB/s!

Второе -- я не замечал разницы в ширине записи между IDE, SATA и SCSI при равных RPM. Другое дело, что 10KRPM доступнее для SCSI: 10KRPM SATA -- совершенная экзотика, и по цене совершенно не отличается от SCSI...

Слабо верится, что 10KRPM на pci хуже, чем 7KRPM на pci-x... Хотя, конечно, если говорить про массивы, то все определяет именно шина. Но -- если массивы достаточно большие (>4).

> никак не меньше 400 MB/s!

ограничение, заложенное в протоколе или ограничение его реализации?

> sync НЕ ПОМОЖЕТ!!! Нужен umount!

да? и в чем разница?

> Слабо верится, что 10KRPM на pci хуже, чем 7KRPM на pci-x..
> .. все определяет именно шина.
> .. большие (>4)

ты настроил себя найти узкое место в чем угодно, только не в шине?
напиши, что покажут тесты на pci-x контроллере

>> sync НЕ ПОМОЖЕТ!!! Нужен umount!

> да? и в чем разница?

Думаю, в багофичах Линукса.

Проверено, после sync с-под оболочки львиная доля остается где-то в Линуксовых буферах, диким образом зависимо от версии ядра/драйверов.

Кроме того, оно довольно непредсказуемо: действует на ВСЕ файловые подмонтированные системы, коих может быть множество.

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

Короче, проверено -- с-под шелла гоняться за истиной следует с помощью umount. Эмпирический факт...

> ты настроил себя найти узкое место в чем угодно, только не в шине?

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

На самом деле, как я понимаю, дело в балансе bandwidth и latency. Очевидно, эти величины в некотором смысле противиположны. В последние годы для примерения этого противоречия маркетоиды придумали хитрый термин MT/s (Mega)Transfers/seconds или IOP (Input-Output per seconds) Некие _эффективные_ характеристики, призванные успокоить мечущийся разум туповатого высокооплачиваемого IT консультанта -- типа, чем больше, тем лучше.

Наверное, имеются некие эмпирические формулы перехода от MT/s к MB/s и обратно, в результате применения которых шина 160 MB/s чудесным образом превращается в шину 320 MB/s...

Вдогонку:

> Проверено, после sync с-под оболочки львиная доля остается где-то в Линуксовых буферах

Если мне не изменяет память, sync только сбрасывает буфера и _инициирует_ пробуждение bdflush, вызывая man 2 sync

Оно возвращается сразу, как только сброс на диск _заработал_, но сам процесс сброса иногда занимает часы!

2Chubaka:

Еще вдогонку:

Поверь, я много игрался с терабайтным I/O в надежде постичь Истину...

Эмпирический факт: истина начинает проявляться после того, как ты превышаешь максимально доступный объем _виртуальной_ памяти на порядок. До этого все крутится вокруг кышей и текущей активности...

>> никак не меньше 400 MB/s!

> ограничение, заложенное в протоколе или ограничение его реализации?

Производители psi карточек уверяют, что оно работает в соответствии со стандартом, на 500 MB/s

> напиши, что покажут тесты на pci-x контроллере

Да, обязательно напишу.

Только оно может занять несколько дней...

Я сюда отпишу, а потом подожду твоего ответа (что, типа, прочитал). Если за пару дней не дождусь, открою новый топик в General.

>Если за пару дней не дождусь, открою новый топик в General.

не стоит. треду буквально несколько дней

>Одного не понимаю: зачем тогда все эти слова про Ultra-320, если оно более 100 не тянет?

шины тянут. не тянет только их процессор на рейд-контроллере

>Обещают на днях прислать 2-канальный рейд контроллер на PSI-X

наверное PCI-X?

я думаю было бы лучше два одноканальных.

>> sync НЕ ПОМОЖЕТ!!! Нужен umount!

>да? и в чем разница?

баги в дровах.

> Проверено, после sync с-под оболочки львиная доля остается где-то в Линуксовых буферах

если мне не изменяет, не в линуксовых буферах а в именно в кэше харддрайва.

но в случае хардовых рейдов дисковые кэши должны отключаться, во всяком случае это рекомендуется стоматологами страны для fault-tolerance, тем более на режиме write-back с установленной автономной батарейкой на контроллер.


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

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

вообще, раз уж пошла такая пьянка, хорошо бы детально смотреть разницу в происходящем на x86_64 системе в pci и pci-x

> Только оно может занять несколько дней..

ок. подождем

>да? и в чем разница?

> баги в дровах.

простите, не понял в каких дровах?

>но вобщем "по ощущениям" могу сказать, что scsi массивы на pci работают медленне, чем саташные на pci-x

у них НЕМНОГО большие канальные задержки но НАМНОГО выше масштабируемость на несколько ОДНОВРЕМЕННЫХ потоков записи чтения особенно нелинейных.

натрави на свой массив одновременно 100 потоков на чтение и столько же на запись и узри что производительность просядет больше чем на порядок.

для сказей производительность просядет ~2 раза.

насколько я знаю в драйверах рейд-контроллеров.

>На самом деле, как я понимаю, дело в балансе bandwidth и latency. Очевидно, эти величины в некотором смысле противиположны. В последние годы для примерения этого противоречия маркетоиды придумали хитрый термин MT/s (Mega)Transfers/seconds или IOP (Input-Output per seconds) Некие _эффективные_ характеристики, призванные успокоить мечущийся разум туповатого высокооплачиваемого IT консультанта -- типа, чем больше, тем лучше.

"маркетоиды придумали хитрый термин MT/s (Mega)Transfers/seconds" - это придумали гдето в 1970 году когда была создана первая версия скази производительностью 5МТ/с

>Наверное, имеются некие эмпирические формулы перехода от MT/s к MB/s и обратно, в результате применения которых шина 160 MB/s чудесным образом превращается в шину 320 MB/s...

могу разочаровать. формул перехода не существует с момента появления стандартов 160мб и 320мб. там сильно порезали классическую концепцию скази.

шины 160мб и 320мб физически различаются. на вид не знаю ибо видел только 320мб.

>На самом деле, как я понимаю, дело в балансе bandwidth и latency.

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

> больше чем на порядок.

на внешних хардовых контроллерах и scsi и sata на схожих типах рейдов тенденции одинаковы.
на набордных саташных - да, согласен.

насколько я помню в случае внешних корзин с интерффейсами scsi и FC гдето так оно и есть. в смысле производительность корзины мало зависит от типа дисков которыми она наполнена

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

я имел ввиду случай когда у нас pure-sata система. тоесть PCI(X) sata-рейдконтроллер.

мне показалось что die-hard корзин не пользует.

> насколько я помню в случае внешних корзин

я имел ввиду, "чип находится на матери и использует системные память и cpu" vs "самостоятельная pci(-x) карта со своей памятью и cpu."
не понял exactly, честно говоря, про какую ты карзину, все корзины которые я видел, это просто металлические боксы в самом корпусе(обычно 3-х юнитовом) для дисков, которые могут быть подключены и к "на-матерным" разъемам.
а отдельные NAS платформы на iSCSI и FC это уже, по сути, полноценные машины.
если ты про какие то out-unit'овые штуки, которыми можно просто увеличевать диское простр-во имеющейся платформы, (если, конечно, это не фантазия у меня разыгралась) можно уточнить и ссылок? на самом деле интересно было бы посмотреть.

под корзинами я понимал что-то типа этого:

"SANnet II SATA" и что-то типа "SANnet II FC"

http://www.dothill.com/products/storage.htm

конкретные железки FC но есть такие же SCSI. просто я идею или свою мысль проиллюстрировал.

ага, понял.
> конкретные железки FC но есть такие же SCSI
scsi и FC это по назначению несколько разные уровни общения девайсов.

ну вобщем да, это другая история, для таких девайсов транспортом scsi/sata/ata комманд служит не системная шина, а сеть

>Производители уверяют, что хардварная ширина записи на диск составляет 800 MB/s

хай не врут. сам рейд-контроллер с корзиной на 500МБ/с стоит 30000$-50000$ и то кажись без дисков.

ниразу не слышал чтобы более дешёвые девайсы давали соизмеримую производительность.

ещё можно спросить на sql.ru в форуме oracle. Там много парней которые в этом настоящие guru.

> ширина записи на диск составляет 800 MB/s
> хай не врут.

кстати, да, откуда число?
800 вот вижу только в контексте частоты сист. шины (FSB)

> сам рейд-контроллер с корзиной
ну вот эти SANnet'ы это существенно поболе, чем просто рейд контроллер, это вполне самостоятельный девайс для _сетевой дисковой фермы, среда его работы - сеть, а задачи - разделяемость по сети.
Просто, ему не нужен FC свитч, у него на спине много FC портов.

А выжать 800MB/s из ultra320 это да, это как догнать Совранского.