Мда, господа хорошие, ну и флейма вы развели. А вопрос-то выеденого яйца не стоит. По большому счету все железо одинаково (если там багов нет). Все таже машина господина Тьюринга, с вариациями. Софт другой вопрос, можно и подобосраться, но как правило современные ОС-ки пишут грамотные люди. Итого - все в принципе равно по своей сути. Главный момент в том что _линукс_ именно на _x86_ очень вовремя попал в струю, как это не трудно видеть. И собс-но все, лет через 5 везде (ну ok в 80% случаев) будет линукс на x86, x86_64, x86_128, ... Кто тут действительно спрухал, так это Интел. Те кто этого еще не понял и пытается цепляться за свои наработки с кучей вбуханного в них мега $ лишь оттягивают свой конец в долгий ящик. Медленносоображающие просто вымрут. IBM вот поняли в чем дело и забрасывают свой AIX куда подальше. Это большой брат-то! А Сун слишком консервативен и неповоротлив, хотя вот новые менеджеры пришли... Скотт Макнилли в аут... Java Desktop System... Может и побарахтаются.

Итого - надо концентрироваться на софте (ага под линукс), а за железо за вас будет Интел думать уже.

-- Оракул

Однозначно SGI рулит уже серваки с 256 процами под одним ядром. Под Linux следует заметить. И я не за что не поверю что туда невозможно вдуть Oracle. И боллее серьезные задачи там крутятся и ничего не подает. Так что по поводу проверенной архитектуры SUN ...

2no-dashi (*) (12.04.2004 21:37:25)
no-dashi, не надо глупых отмазок в стиле местных дефективных детишек, да?
Типа у нас этого нет, потомучта нам это не нужна.

Это ограничение x86 архитектуры, точно также как и хреновый i/o. В конце концов, сходи на tpc.org и посмотри где там интел, а где риски.

>Если быть точным, цена зеона MP с 4 метрами кэша составляет $6000, а цена того камня, что стоит в x445, составит меньше $4000. Вывод - мы получим 12-ти каменную железку за $40+$32=$72 - почти в два раза, или на 67 (!) килобаксов меньше, чем у сана.

Для того, чтобы получить 12-процную конфигурацию для 445 нужно ТРИ модуля по 40 килобаксов, а не один модуль и 12 процессоров, как ты посчитал. Так что твои вычисления неправильны изначально.

Ты вообще читать по английски умеешь - линукс только до 8-процессоров: "Support for up to 8-way scalability with Red Hat Enterprise Linux, SUSE LINUX Enterprise Server,..."

>Если IBM предлагает на них Linux, значит он там пойдет

А если IBM скажет что 2х2=5, о это тоже верно?

2no-dashi:

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

А вообще, из того, что Intel хорошо заточен под однопроцессорную/мало-процессорную архитектуру, не следует ждать от Intel больших результатов и на SMP, хотя времена меняются...

>>> И еще есть у меня одно предположение, что 4-х каменная железка с сердцами по 3 гигагерца, 4 метрами кэша на камень и 566-MHz шиной разделает 4-х головую спарку на британский флаг, а с 8-ми головой потягается как минимум на равных... Но это только догадки. С учетом специфики БД-шных задач, блокировок там будет не так мноо (при правильной настройке сервера), и гипотетическое преимущество солярки в SMP роли особо не сыграет. Впрочем, это уже только мое IMHO.

>Во-вторых, для Oracle, например, существуют Shared Instances

Чего-чего? Это ты RAC так обозвал что ли? Так если RAC, то там не все так просто, как ты описал - один инстанс OLAP, другой инстанс - OLTP. Кстати, в случае интенсивной OLTP задачи, RAC может быть намного хуже классического оракла на SMP-машине.

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

> Это ограничение x86 архитектуры, точно также как и хреновый i/o

Хреновый I/O - это ограничение криворуких администраторов!

Стоит вон 4000-й энтерпрайз, так у него затык тоже в I/O, и никакая ультраспарковая суперскалярность не помогает, не смотря на KAIO - контроллеры не справляются - но я же не кричу, что это "ограничение архитектуры Sparc", а спокойно говорю, что это ограничение железки, которую надо выкинуть нах&^%%й по причине возраста.

Ограничение в 4 GB - да, это ограничение размера плоского адресного пространства x86, доступного "напрямую". Но теперь пойдет специально для самых умных: если залезть в google, и сказать max oracle sga size on linux x86, в первых трех документах попадется ссылка на PDF-ку под названием "Deploying Oracle9 i on RedHat Enterprise Linux AS", где русским по белому написано:

The Red Hat Enterprise Linux kernel includes a VM subsystem that supports an SGA signficantly beyond this size, up to a theoretical maximum of 62 GB.

И сделано это было By working closely with Oracle to perfect the technology underlying Red Hat Enterprise Linux AS - это из того же документа.

Аргументы доведедены до вашего понимания?

>> Во-вторых, для Oracle, например, существуют Shared Instances

> Чего-чего? Это ты RAC так обозвал что ли?

Это НЕ RAC. Это именно различные экземпляры, работающие на одной базе. Съезди на курсы оракловые, там тебе доходчивей объяснят (ну или книжку возьми, там это тоже написано).

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

В реальной жизни такое бывает, что ни в сказке сказать, ни пером описать - как например, тот факт, что 2-х процессорный сервер с более быстрым дисковым I/O и двукратно более процессорами делает раз этак в 8 по производительности шестипроцессорный гроб от той же фирмы.

В общем, Sun - это почти религия. Раньше религией был DEC, потом Sun... Только DEC умер, и Sun умрет. Ну ладно - пусть не умрет, а будет куплен на корню Fujitsu-Siemens :-)

2no-dashi (*) (13.04.2004 11:56:08)
"Хреновый I/O - это ограничение криворуких администраторов!"
Угу, пока интел нормальный не сделает:)
no-dashi, не опускайтесь до уровня мастеров жанра, запустивших линуксовый маршрутизер на асустековой маме, и утверждающие, что продуть e1 через пецуковый PCI это вопрос смекалки и растущих откуда надо рук.

"Но теперь пойдет специально для самых умных: если залезть в google, и сказать max oracle sga size on linux x86"
Ну:) ИМХО отличный пример воркараунда для обхода ограничений х86. Это не отменяет недостатков самой архитектуры. Впрочем ответ на мой вопрос вполне прозвучал.

"Аргументы доведедены до вашего понимания?"
Да. Вполне. Я Вас вполне понимаю и даже на слово верю, учитывая что Вашие мнение сформировано как я понял на основании работы с 7-м солярисом и спарками девятьсот лохматого года.

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

2Krause:
Не будете ли вы так любезны объяснить нам связь между недостатками архитектуры x86 и операционной системой GNU/Linux ?

у нас в серъезной организации в городе линух на шкварках.

2anonymous (*) (13.04.2004 16:25:17)

"Не будете ли вы так любезны объяснить нам связь между недостатками архитектуры x86 и операционной системой GNU/Linux ?"

Анонимусы:)

не захлебнись только =) с твоим церебральным параличем - плевое дело =)

усраныч наверное перед тем как отдать свои яйца на отбив на пасху наклеил на них логотипы сана. а потом ему молотком по логотипу - хуяк! =))

>>Анонимусы:)
Бывший министр Краузе

Эх, жаль, не было ЛОРА во времена как DEC загибалась. Тогда бы тоже крутые дяди орали
как DEC всех ставит раком, другие чудаки на букву "М" обвиняли бы топик, оффтопик, этц.
Впрочим, надо признать, оффтопик им немного помог.
Крики типа у Интела хреново то, у Интела хреново сё Сану уже не помогут. И еще: на Итаниуме
все так же фигово? Или уже чуть по лучше?
Вообще то ИМХО самым началом их конца был момент, когда они вместо S-Bus начали
везде лепить PCI. В лучшем случае их участь стать средней конторкой производящие
не лучшие х86/АМД-64 бэйс железячки.
И со связкой Интел+НР=Итаниум они тоже про*бут. Дело времени.

Лишь о том, что всё пройдет вспоминать не надо. (с).

e1 & pci

> утверждающие, что продуть e1 через пецуковый PCI это вопрос смекалки и
> растущих откуда надо рук.
вот именно.
продуть E1 через любой комп с pci не просто , а очень просто. даже есть выбор плат: sbei, sangoma, cronyx, digium и куча менее известных.
jfyi: E1 - это всего навсего max 31 канал по 64 кбит/с (~2 мбит/с). а обычный эзернет, как известно, max 100 Мбит/c, тем не менее не вызывает проблем с рутингом между 2-6 эзерами даже у p-100.
я не понимаю, в чём сложность? cronyx делал платы E1 даже для ISA.
http://www.cronyx.ru/hardware/tau.html
или Вы ирси подменяете?8)

> Вас вполне понимаю и даже на слово верю, учитывая что Вашие
> мнение сформировано как я понял на основании работы с 7-м
> солярисом и спарками девятьсот лохматого года.

Опа! А кто говорил, что однажды приобретенное железо и софт поддерживаются годами, и на эти же многие годы их хватает, ибо в них достаточно просто компоненты заменять? Может, конечно, я вас и не процитировал, господин Krause, но смысл ваших утверждений в наших извечных спорах был именно таков. Или вы ссылочку на документ ждете?

> ИМХО отличный пример воркараунда для обхода ограничений х86.
> Это не отменяет недостатков самой архитектуры

Тем не менее, это является вполне корректным решением проблемы.

> no-dashi, не опускайтесь до уровня мастеров жанра, запустивших
> линуксовый маршрутизер на асустековой маме, и утверждающие, что
> продуть e1 через пецуковый PCI это вопрос смекалки и растущих
> откуда надо рук.

Да, продуть даже 20 потоков E1 на несчастном "пецуке" никогда не было проблемой (требуется только наличие плат). Как вам правильно заметили, E1 - это всего 2 мегабита :-)

Что же насчет ввода-вывода - так вами нелюбимый "пецук" трехлетней давности прогоняет 30МБайт в секунду при чтении с винта без усилий (причем 30МБ - это именно ограничение винта) - даже на железке известной фирмы "NoName". Тех же времен компаки и хьюлеты прогоняли по 50-60 мегабайт в секунду без каких-либо затруднений - речь идет о выводе на хороший контроллер, естественно, когда данные влетают в его кэш.

2mumpster (*) (13.04.2004 20:30:07)
Через обычный 32 битный PCI? На асусной китайской маме? Я тебя умоляю...
pci-x еще туда сюда и с нормальной картой... Но цена такого вопроса - не
пецук с $150 материнкой. Вот.

>Это НЕ RAC. Это именно различные экземпляры, работающие на одной базе. Съезди на курсы оракловые, там тебе доходчивей объяснят (ну или книжку возьми, там это тоже написано).

Не надо ходить на дорогущие курсы.Вот тебе ссылочка: http://download-uk.oracle.com/docs/cd/A87860_01/doc/index.htm - почитай и уясни для себя, что если ты хочешь одну БД и несколько инстансов, то это Oracle Parallel Server для 8 и Real Application Clusters для 9. Вполне возможно, что можно на одном сервере поднять несколько инстансов, чтоб делили одни файлы данных, но это будет точно жуткий геморой, да и по ресурсоемкости это будет не хило - отдельная SGA для каждого инстанса, причем размерами эти SGA не будут сильно отличаться.

По любому RAC или OPS подходят для ограниченног круга задач, например, для некоторого подмножества OLAP. Если же интенсивный OLTP, то с кол-вом узлов будет линейно возрастать трафик между ними, связанный с локировками ресурсов (термин не помню точно, не спец по RAC). И тогда, например, двойной гигабитной NIC может и не хватить.

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

>Стоит вон 4000-й энтерпрайз, так у него затык тоже в I/O, и никакая ультраспарковая суперскалярность не помогает, не смотря на KAIO - контроллеры не справляются - но я же не кричу, что это "ограничение архитектуры Sparc", а спокойно говорю, что это ограничение железки, которую надо выкинуть нах&^%%й по причине возраста.

>В реальной жизни такое бывает, что ни в сказке сказать, ни пером описать - как например, тот факт, что 2-х процессорный сервер с более быстрым дисковым I/O и двукратно более процессорами делает раз этак в 8 по производительности шестипроцессорный гроб от той же фирмы.

А у вас используются внутренние диски что-ли на 4000 для бизнес-приложений? Не смещите мои тапочки, внутренние диски на таких серваках, только, чтобы ОС функционировала и ни для чего больше. Наверное есть дисковый массив, наверное старый и наверное SCSI. Так поменяйте массив и HBA к нему, вот ваши проблемы и решаться. А enterprise 4000 добротно сделан, не то что сейчас сан клепает, такая техника лет 10 сможет работать и хоть бы хны. Только админы должны быть рядом толковые.

2no-dashi (*) (13.04.2004 23:39:33)
"2Опа! А кто говорил, что однажды приобретенное железо и софт поддерживаются годами"
Я говорил.
"Стоит вон 4000-й энтерпрайз, так у него затык тоже в I/O, и никакая ультраспарковая суперскалярность не помогает, не смотря на KAIO - контроллеры не справляются -"
- Ваши слова? Когда вы этот агрегат купили - у него тоже контроллер затыкался? Наверное нет. И наверное у Вас сейчас он затыкается не от старости лет. Наверное у вас нагрузки выросли только и всего.
А апгрейд/замена у Вас по каким-то причинам не катит. Так о чем спор то?


"Тем не менее, это является вполне корректным решением проблемы. "
Угу, которй на рисках вообще НЕТ.

"так вами нелюбимый "пецук" трехлетней давности прогоняет "
Напомните мне пропускную способность шины на пецуках и спарке трехлетней давности.

>Да, продуть даже 20 потоков E1 на несчастном "пецуке" никогда не было проблемой (требуется только наличие плат). Как вам правильно заметили, E1 - это всего 2 мегабита :-)

Ого-го, 20 потоков E1. Максимум, какие были платы у Dialogic, Septel и сейчас у Intel - это по 4 потока. Итого должно быть 5 таких PCI плат, чтобы потянуло 30 потоков. Покажите мне писюк, где вы сможете без гемороя заставить работать такую конфигурацию.

> Наверное есть дисковый массив, наверное старый и наверное SCSI

Естественно массивы, и естествеено апгрейднуты энное время назад, с тех пор актуальность проблемы несколько ослабла.

> такая техника лет 10 сможет работать

У такой "техники" процессоров и на пять лет не хватит - с момента покупки количество процессоров учетверилось, посему "это" еще живо, но сделанная на три года позже железка рвет его на джек юнион :-) Просто за счет того, что 4 процессора по 400MHz быстрее под двумя аппсерверами и двумя базами, чем 8 процессоров по 267MHz под одной базой и одним аппсервером. Теперь можешь прикинуть, что произойдет, если разница в частотах будет трехкратной :-)

> > Тем не менее, это является вполне корректным решением проблемы.

> Угу, которй на рисках вообще НЕТ.

И на 32-битных спарках тоже? :-)

> Напомните мне пропускную способность шины на пецуках и спарке трехлетней давности.

Какой из шин? Я ведь спокойно могу сказать, что пропускная спосбность сановского PCI не превосходит пропускной спосбности PCI на x86, и буду абсолютно прав :-) А ты должен возмутиться, и начать рассказывать про то, что PCI отстой, и вес контроллеры будут садиться на спарках на очень крутой interconnect который всех зарулит...

> Покажите мне писюк, где вы сможете без гемороя заставить работать такую конфигурацию

Давайте отделять мух от котлет - и софтовые проблемы драйверов от пропускной способности шины. Затыка на шине НЕ БУДЕТ. Это факт. А проблем с драйверами - скорее всего тоже не встретите, но это уже IMHO.

мне вот что интересно. если вся эта экзотика настолько крута, почему у меня на работе и дома не она? почемку 99% техники на работе не она? это все напоминает историю про построение коммунизма в отдельно взятой стране.

2no-dashi (*) (14.04.2004 10:54:09)
"И на 32-битных спарках тоже? :-)"
Нет. Только 32 бита для спарков это вчерашний день. А для интелей - сегодняшний. Когда интел сделает 64 битный проц, когда он пойдет в массы, когда под него налабают софт - тогда этот вопрос будет снят с повестки дня... А пока...пока мы сидим и курим:)

"Какой из шин? Я ведь спокойно могу сказать, что пропускная спосбность сановского PCI не превосходит пропускной спосбности PCI на x86,"
Цифирки назови:)
У v880 1.5 Gb/s, у 3800 4.8, у 15k 43гиг в секунду c хвостиком:)

2anonymous (*) (14.04.2004 12:04:52)
"мне вот что интересно. если вся эта экзотика настолько крута, почему у меня на работе и дома не она? почемку 99% техники на работе не она"

А, так, без обид, ты где рабоаешь то? :)
Видишь ли, дело в том, что когда организация и/или степень ее потребностей в автоматизации переростают определенный предел - вся эта ботва перестает быть экзотикой, а становится насущной необходимостью (не обязательно саны или еще там кто). Проблема в том, что 90% контор НЕ дорастают до потребностей в как ты говоришь "экзотике", и вполне обходятся среднпаршивом ширпотребом. Только и всего.

PS Дома у меня тоже спарков нету:)

ну дык разделил правильно сектора а потом все равно скатился до фразы о ширпотребе. начал за здравие, а... ;)

> У такой "техники" процессоров и на пять лет не хватит - с момента покупки количество процессоров учетверилось, посему "это" еще живо, но сделанная на три года позже железка рвет его на джек юнион :-) Просто за счет того, что 4 процессора по 400MHz быстрее под двумя аппсерверами и двумя базами, чем 8 процессоров по 267MHz под одной базой и одним аппсервером. Теперь можешь прикинуть, что произойдет, если разница в частотах будет трехкратной

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

Процессоры по 267 Mhz, хм, а когда это было куплено? Я в 1999 впервые стал санами заниматься, так они тогда уже на enterprise предлагала спарки 400/8.

Про трехкратную частоту это ты ксеон имеешь ввиду? А какая у него скорость шины процессор-память, напомни плз?

> Только 32 бита для спарков это вчерашний день. А для интелей - сегодняшний

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

> У v880 1.5 Gb/s, у 3800 4.8, у 15k 43гиг в секунду c хвостиком:)

PCI??? Не верю.

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

Цифры реально пропускной способности примерно следующие: частоты СИСТЕМНОЙ * разрядность ее же. Итого теретические циферки будут для топовых процессоров 800000000*32=25600000000 - 25 гигабит (теоретическая цифра), рельно будет около 20-ти. Моя машинка с частотой шины 100MHz должна по этой методике давать около 3 гигабит (реально около 2.5)

А теперь пошли удары ниже пояса: делаем тривиальный тест - обычный memcpy в цикле, 1000 повторений по 4 мегабайта, и замеряем время. Результат - 12 с половиной секунд. 4 гигабайта, 32 мегабита, 12 секунд - получается чуть больше 2.5 гигабит. Опять же, 100 мегагерц, 32 бита - должно быть 3.2 гигабита в секунду. Поскольку у меня Celeron со 128k кэша, 4 метра гоняются именно по направлению процессор<->память, т.е. результат можно считать достоверным. Вот тебе и циферки реальной пропускной способности "пецука". Кажется, v880 отдыхает, ведь Gb/s и Gbps означают gigabit per second? Да и 3800 недалеко ушел.

А ведь они предлагают v880 в том числе как Visualisation server - и не стыдно сантехникам, а? Машинка, которая должна гнать данные потоком, уступает напрочь гнилому "пецуку" :-/

Напрашивается неприятный вывод - на рынке рабочих станций и серверов до 8 процессоров "сраные пецуки" вокруг "реально крутых санок" кругами бегают не запыхиваясь :-)

> Про трехкратную частоту это ты ксеон имеешь ввиду?
> А какая у него скорость шины процессор-память, напомни плз?

566 :-) Или 800 у "свеженьких" :-) Смотри пост выше - там все рассказано

Проблема с пропускной способностью у санок была и будет еще долго - из-за их NUMA-подобности :-)

e1

> Через обычный 32 битный PCI?
да, а что тут такого.
ешё раз для тех кто в танке: e1 = это всего лишь 31x64 кбит/с + 1 служебный. если продуть 10 мбит/с не представляте проблемы даже у isa 16-bit, то какие проблемы могут быть у pci?8-)
ссылочку я вам дал на isa e1 плату - это работало...

> А какая у него скорость шины процессор-память, напомни плз?

да, и еще - я соврал про скорость процессор-память. Она в два раза ниже, ибо приличная память работает на 400MHz. Ну и пропускная способность процессор-память для нормальных свежих моделей x86-х будет, соответствено, 12 гигабит в секунду (исходя из 32-бит) - тем не менее, прочастоту FSB и ее пропускную способность я вроде бы не должен был обмануть.