LINUX.ORG.RU

Opteron IO performance?


0

0

Странное явление.

Opteron 4x DualCore, RAID0 4x-SCSI (Ultra-320, 10 KRPM) 4x300 GB, Raid железячный.

Не получается выжать скорость записи больше 80 MB/s

Рядом стоят Альтиксы (ItaniumII от SGI), на них просто диски без Raid железяки, тоже SCSI Ultra-320 10 KRPM, соединенные в один том с помощью XVM -- около 300 MB/s пишут.

Два вопроса:

1. Это что, действительно фича Оптерона? То есть, ширина записи на диск 80 MB/s для Оптерона -- предел?

2. Как под стандартным Линуксом подергать SCSI (манипулировать очередями, кэшами и прочей лабудой)?

Собственно, история вопроса:

Некоторое время назад коллега пожаловался, что на 4-х головом Оптероне при попытке писАть на один диск (СКАЗИ) 4 потока в параллель начинаются жуткие тормоза. Грешили на Линукс, но я погонял тесты на Альтиксе -- ни малейших тормозов вплоть до 32 параллельных потоков. Потом прозвучало мнение, что просто Оптероновская архитектура, основанная на HyperTransport со свичем на процессоре, ущербна по части I/O.

На днях купили и мы 4-х главый Оптерон Dual core. CPU масштабируются отлично, все speedup кривые до 8 в точности совпадают с теми же, полученными на 8-головом Альтиксе, но это только пока оно не начало на диск писАть. Как только тест начинает работу с диском, Оптерон начинает тормозить...

Обидно! Оптерон стОит в 3.5 раза дешевле и считает в 2 раза шустрее 8-голового Альтикса (за счет бОльшей тактовой частоты). Что ж дисковым I/O - то творится?

★★★★★

Ответ на: комментарий от Chubaka

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

SANnet-ы не всостоянии обеспечить 500Mb/s

cvv ★★★★★
()
Ответ на: комментарий от cvv

> не для построения SAN а для использования в NAS
и там и там сеть. FC это сеть.

> внешний винчестер с двумя интерфейсами SCSI-320

то есть, типа того, что в "корзине" на спине обычный scsi разъем?

Chubaka
()
Ответ на: комментарий от Chubaka

>> внешний винчестер с двумя интерфейсами SCSI-320

>то есть, типа того, что в "корзине" на спине обычный scsi разъем?

да. именно об этом речь. что вас при упоминании FC чрезмерно к SAN-ам тянет.

SCSI - тоже сеть в некотором смысле, правда заметно менее удобная

cvv ★★★★★
()
Ответ на: комментарий от cvv

>>> внешний винчестер с двумя интерфейсами SCSI-320

>>то есть, типа того, что в "корзине" на спине обычный scsi разъем?

> да. именно об этом речь.
> что вас при упоминании FC чрезмерно к SAN-ам тянет.
> SCSI - тоже сеть в некотором смысле, правда заметно менее удобная

потому что FC это сеть :)

ну вобщем да, сам интерфейс scsi где то на физическом уровне osi положить можно.
а ATA/IDE/SATA вы тоже готовы назвать сетью в некотором смысле?

ps. кстати, когда-то где-то читал про попытки инкапсулировать ip в scsi, но не отследил, чем закончилось.



Chubaka
()
Ответ на: комментарий от Chubaka

>ps. кстати, когда-то где-то читал про попытки инкапсулировать ip в scsi, но не отследил, чем закончилось.

закончилось что сказя нормально работала как сетевуха.

проэкт не развивается для ParalellSCSI в силу быстрого наступления SerialSCSI и FC

у меня в городе сказёвые хост-контроллеры в продаже отсутствуют как класс

cvv ★★★★★
()
Ответ на: комментарий от cvv

cvv:

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

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

Практически всегда они обратно пропорциональны друг другу.

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

Die-Hard ★★★★★
() автор топика

короче, предложили нам MegaRAID 320-2X 120MB

Показали бенчмарки. Тот, что раньше, давал 146 на чтение и 80 на запись. Новый должен давать 303 на чтение и 264 на запись.

Посмотрим...

Die-Hard ★★★★★
() автор топика
Ответ на: комментарий от Die-Hard

там ещё есть третья степень свободы в виде кажись масштабируемости. тоесть балансировать нужно не между двумя а тремя параметрами.

балансировка между bandwidth и latency при отсутсвии ограничений по третим параметрам собственно балансировкой не является;-)

//cvv

anonymous
()
Ответ на: комментарий от anonymous

> балансировка между bandwidth и latency при отсутсвии ограничений по третим параметрам собственно балансировкой не является;-)

Я ж говорю -- "Практически"!

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

Все.

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

Die-Hard ★★★★★
() автор топика
Ответ на: комментарий от Die-Hard

так понятней

а теперь представь что этот пакет в одном случае проходит через шину скази а в другом случае через стек протоколов IP или FC.

так вот задержки создаваемые стеком протоколов на ПОРЯДОК польше задержек пакетной коммутации которой на шине скази НЕТУ вообще

cvv ★★★★★
()
Ответ на: комментарий от Chubaka

Chubaka:

Только сегодня вернулся, тесты без меня делали.

> что тесты показали, теоретик? :)

Я в шоке!

Новый контроллер лишь на проценты лучше старого.

Оторвали контроллер, соорудили массив на LVM -- Я в шоке! Почти то, что надо!

Все еще хуже, чем на Альтиксах, но под 200 MB/s имеем. А, главное, мастабируемость по количеству писателей нормальная.

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

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

Die-Hard ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.