Новые процессоры от Sun и Fujitsu установили новые рекорды

> про ниагару и smt уже говорено-переговорено, уже давано озвучео что Ораклу и прочим тяжёлым СУБД подавай настоящее SMP. Т.е., в Вашем случае считайте что у Вас 8 ядер.

даже мне, человеку ни разу в жизни не видевшего продукцию сана и то смешно.

> Сколько именно CPU
show boards подсветите - я отвечу. а то непонятно - то у вас 24 cpu то уже 12. ну или кол-во юнибоард скажите - 3 или 6.
но вообще - в CMU M8000 4 SPARC CPU, как и у амазона (E25K). не как в M5000. то есть туда можно воткнуть 4 платы и получить 16 SPARC VII.

> show boards подсветите - я отвечу. а то непонятно - то у вас 24 cpu то уже 12.

e25k - 12cpu х2core, 24ядра. На SPARCIV+ разницы проблем с одновременной работой 2 ядер на процессоре нет.

> в CMU M8000 ... можно воткнуть 4 платы и получить 16 SPARC VII.

на которых нужно поотключать 6-7 нитей из 8 на CPU чтобы они работали соизмеримо со SPARCIV+ под "Oracle и другими тяжелыми БД"? На процессоре а 2(3) поколения выше, стоящем в энтерпрайз сервере?

dk-> даже мне, человеку ни разу в жизни не видевшего продукцию сана и то смешно.

А я вот практически плачу горючими слезами.

>чтобы купить сервер для СУБД от Сана, нужно считать сокеты а не ядра, и отключать по 7 нитей из 8 на сокете. Тогда будут нормально работать оракл и прочие тяжелые субд.

как тогда объяснить первую строку tpc-c на T5440, поставленных еще и раком ?

> на которых нужно поотключать 6-7 нитей
...
> А я вот практически плачу горючими слезами
послушай, уйдём в личку - может чем помогу, всё-таки это LOR а не SOR.:-)

> на которых нужно поотключать 6-7 нитей
просто есть вот такие интеерсные вещи:
http://kevinclosson.wordpress.com/2006/11/30/marketing-efforts-prove-sunfire-...
очччень много зависит от настроек и поставленных обновлений.

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

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

>типа SunFire 4800
>получив тем самым до четырёх независимых серваков

ага, на 4800 c тремя SB и друмя IO - четыре домена?
процессоры между доменами научишь перебрасывать?

>У Сана больше нет серверов с "нстоящим SMP" кроме интеловых

Куда бы оно делось-то?

Как между сокетами, так и между ядрами внутри одного кристалла вполне себе SMP. Разумеется ни SMT в SPARC64, ни CMT в Ниагаре не дают линейного увеличения производительности (как и HyperTreading в Intel), но этого ни кто и не обещал. Более того, всегда спецом подчёркивается, что вещи типа CMT подходят только узкому кругу задач или требуют специальной заточки ПО. Собственно, хочу сказать, что и увеличение количества ядер внутри чипа тоже не даёт линейного прироста, и это у всех производителей процессоров, и это никто не скрывает.

Если кому-то из вас некто навешал на уши, что 1 SPARC64 VII эквивалентен 8 UltraSPARC III (при равенстве тактовых частот) или отвлечённо - 1 4-ядерный процессор с 2 потоками на ядро эквивалентен 8 одноядерным, и вы на это повелись - то вы лох. Извините...

> Про волшебные настройки
вот есть хороший блог:
http://blogs.sun.com/glennf/tags/cmt
не хотите в личку - как хотите, но иметь 3 борды в e25k - странно. если у Вас действительно e25k - то проще всего и дешевле всего было бы прикупить ещё SB (пока продают). можно набить ещё 15 штук(!), а вместо IO max cpu с 2 процами поставить.

> а вместо IO max cpu с 2 процами поставить.

С MaxCPU выйдет обломчик...

http://sunsolve.sun.com/handbook_private/validateUser.do?target=Devices/CPU_M...

Notes
6. MaxCPU is not supported when UltraSPARC IV Uniboards are installed in the system.

Да и нет их в Full Components List для E25K (что, вполне ожидаемо).

>32 процессора SPARCVII

надо с терминологией поточнее быть

В М5000 max:
4 CPUMs
8 SPARC64 VII chips
32 cores
64 threads

То, что на нитях одного ядра задачи выполняются медленнее, чем на нитях разных ядер - ежу понятно (хотя, на сайте фуджика, конечно, написано, что они работают параллельно :).
Странно, что задачи на нитях разных ядер одного чипа тормозят. Не сталкивался с таким. Надо попробовать.
Как отключали SMP? psradm'ом отрубили лишние нити?

При высокой нагрузке (и большом количестве параллельных выборок) SMP все равно даст прирост.
В этих импровизированных тестах, vmstat run query, наверное, выше 1 не поднимается.

> Ты запустишь на спарке в зоне винду? :-)

Тут это ведь правда никого не волнует? ;)

> А вот на интеле в QEMU можно запустить SPARC Solaris... Теоретически :-/

Низя :( Не работает, как ни пытался. Только Linux.

> послушай, уйдём в личку

Я не знаю как тут в личку писать ) int0755@rambler.ru или 302-077-850 welcome.

По поводу e25k речь, конечно, об одном домене. И в настоящее время закупка комплектующих для него стоит ненормальных денег)

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

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

Видимо вы не читали начала дискуссии

> вы лох. Извините...

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

Когда речь идет о закупках на лимоны денег, то это "ежу понятно" аргумент слабый :)

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

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

> Как отключали SMP? psradm'ом отрубили лишние нити?

SMT. Да, другого способа не знаю. 1 сокет - 8 virtual cpu. Отключаем нечетные нити - отключаем smt в ядрах. Отключаем 6/4/2 - оставляем 3/2/1 ядро на сокет.

Что это за IBM POWER6 UNIX?

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

>Что это за IBM POWER6 UNIX?
Это IBM AIX. Не очевидно, да.

>> То, что на нитях одного ядра задачи выполняются медленнее, чем на нитях разных ядер - ежу понятно (хотя, на сайте фуджика, конечно, написано, что они работают параллельно :)
>Когда речь идет о закупках на лимоны денег, то это "ежу понятно" аргумент слабый :)

Когда речь идет о закупках на миллионы - выбора не так-то и много: Sun или IBM. Ни у кого более машин со сравнимой пиковой производительностью нет.

>> Странно, что задачи на нитях разных ядер одного чипа тормозят. Не сталкивался с таким. Надо попробовать.
>Учитывая что L2 кэш общий - чего-ж тут странного? Вообще говоря - Сан сам предложил попробовать, чтобы посмотреть как это влияет на производительность.

Ну, как бы, на L2 свет клином не сошелся. Не должно же быть замедления в 2(!) раза. Полная чушь получается.

>> Как отключали SMP? psradm'ом отрубили лишние нити?
>SMT. Да, другого способа не знаю. 1 сокет - 8 virtual cpu. Отключаем нечетные нити - отключаем smt в ядрах. Отключаем 6/4/2 - оставляем 3/2/1 ядро на сокет.

Ну, так другого способа на Sun'ах и нет :)

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

Мы внедряли как-то оракл на RHEL на ibm3950 (2 брика по 4 xeon с HT).
Архитектура той системы не позволяла процессорам одного ящика иметь быстрый доступ к памяти в другом ящике. Вот тут была проблема. Которая так и не решена. Пришлось уменьшть SGA.

>Вот тут была проблема. Которая так и не решена. Пришлось уменьшть SGA.

ну и чем не устроил нума режим оракла ?

> Когда речь идет о закупках на миллионы - выбора не так-то и много: Sun или IBM

Ну да. А когда корпоративный стандарт Sun - то выбора вообще нет)

> Ну, как бы, на L2 свет клином не сошелся. Не должно же быть замедления в 2(!) раза. Полная чушь получается.

Не знаю что сказать. Сандартных тестов у меня нет, гонял процедуры закрытия дня некой АБС, в 8 потоков, т.е. была конкретная задача. И да, тесты комплексные, т.е. их даже тестом процессора нельзя считать, по большому счету. Но задачи действительно рассчетные, и в статистике tkprof > 90% времени это именно процессор. При отключенных нитях результаты следующие: m5k 2cpu/8core - 136min 4cpu/8core - 90min 8cpu/8core - 53min 8cpu/16core - 50min 8cpu/32core - 57min

e25k 76min - в производственном режиме при работающих пользователях.

Меня, повторюсь еще раз, результаты работы системы, которая новее на 5 лет не слишком впечатлили

> как тогда объяснить первую строку tpc-c на T5440, поставленных еще и раком ?

Не знаю. Возможно они оптимально работают с tpc-c тестами. А вот как объяснить что в топе суперкомпьютеров их не видно? :)

> Архитектура той системы не позволяла процессорам одного ящика иметь быстрый доступ к памяти в другом ящике. Вот тут была проблема. Которая так и не решена. Пришлось уменьшть SGA.

NUMA же!

> странно что с такими ценами оно еще шевелиться даже при всей своей крутости

а чем ты их заменишь?

>Что это за IBM POWER6 UNIX?

http://www.sun.com/servers/highend/m9000/performance.xml

>Не знаю. Возможно они оптимально работают с tpc-c тестами. А вот как объяснить что в топе суперкомпьютеров их не видно? :)

ну например тем что характер тестов tpc-c слегка отличается от задач суперкомпутеров. хоть это и странно, но в тестах sap-sd и oebs CMTшные спарки тоже показывают неплохой результат. так что ущербность CMT на тяжелых субд задачах во всяком случае в доступных промышленных тестах не столь очевидна.

нажимаешь плюсик на новости (Tue, 13 October 2009), смотришь более подробную инфу, к сожалению цен там нет, но что-то мне подсказывает что решение на IBM дешевле. (у них там 32 цпу а у сана 64).

Ещё неясно кто тестил, пузомерки желательно независимой стороной тестить, той которая не заинтересована коммерчески. (кстати, а HP вроде тоже ниче так, в большую тройку входит, если я ничего не пропустил).

Надо помнить еще то что оракл прикупил сан, и вроде как они новые спарки разрабатывать не будут, надежда только на фуджицу. (мне спарки нравятся тем что они открытые, наша оборонка например их юзает, вот. А так ibm конечно ibm, особо против них не порыпаешься)

>вроде как они новые спарки разрабатывать не будут

Лари вполне однозначно сказал, что спарки сохранят и на это направление увеличат расходы.

>но что-то мне подсказывает что решение на IBM дешевле

Зря тебе это что-то подсказывает...
Вот к примеру:
http://www.tpc.org/results/individual_results/IBM/IBM_595_20080610_ES.pdf
Subtotal 12,049,638
Так, просто чтобы представлял себе порядок цен.

M9000-64 в $10*10^6 точно уложится.

>ну и чем не устроил нума режим оракла ?
Оракл настраивали инженеры производителя приклада. Да и не занимаюсь я ораклом.
А с какой версии у оракла такой режим появился?

>NUMA же!

SFE25K тоже NUMA. Причем значительно больше NUMA, чем, например, SFE6900. У 6900 репитеры есть, объединяющие SB, а у 25K - System Expander Board + тупой центерплэйн (что в целом работает медленнее, чем репитер у 6900, но зато надежнее).

>2cpu/8core - 136min
>4cpu/8core - 90min
Это, конечно, странно... Не в 2 раза, конечно, а в полтора.

>8cpu/8core - 53min
Тут все четко - по задаче на ядро + накладные расходы ОС.
>8cpu/16core - 50min
Видимо, накладные расходы переползли на доп. ядра.
>8cpu/32core - 57min
..хз че. Задачи попадают на ядра одного процессора и влияет то, что мы наблюдаем в двух первых тестах.

E25K:
24cpu/48core - 76min
Я правильно сделал вывод о конфигурации двадцатипятитонника?

Думаю, на 8-ми cpu без работающих клиентов результат бы не изменился.
Итого, прирост, примерно, пропорционален росту частоты, что вполне ожидаемо.

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

У наших заказчиков параллельно крутится очень много процессов. Одних vxiod по одному на каждый проц :)
На 25К солярис 10 стоит? Или 9-ка?

Мож, настройки какие еще надо подправить?

> Лари вполне однозначно сказал, что спарки сохранят и на это направление увеличат расходы.

дайте ссылку, пожалуйста

>> Лари вполне однозначно сказал, что спарки сохранят и на это направление увеличат расходы.

>дайте ссылку, пожалуйста

http://www.oracle.com/features/suncustomers.html

Целками да интелами в огромных количествами :-(

> Целками да интелами в огромных количествами :-(

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

спасибо

Ну мне кажется вы переоцениваете возможности спарков.

>Оракл настраивали инженеры производителя приклада.

т.е. не сертифицированные ...

>А с какой версии у оракла такой режим появился?

столько не живут, нума это очень далекий предок oracle parallel server из oracle8, т.е. вероятно в середине 90х эта фича уже была. да вон даже не самый продвинутый mssql2005 уже какие-то зачатки нумы имел.

> Ну мне кажется вы переоцениваете возможности спарков.

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

>Это IBM AIX. Не очевидно, да.

Я понимаю. Который из них? Модель сервера и его ТТХ.

>>http://www.sun.com/servers/highend/m9000/performance.xml

Спасибо тебе, добрый человек.

>нажимаешь плюсик на новости (Tue, 13 October 2009), смотришь более подробную инфу, к сожалению цен там нет, но что-то мне подсказывает что решение на IBM дешевле. (у них там 32 цпу а у сана 64).

Угу. Завтра повнимательнее почитаю, но в общем пара тестов меня удивила уже тем, что у ibm ттх по нитям, ядрам в два раза меньше, а производительность ниже всего на треть.

Вероятно, из-за более высокой тактовой частоты?

Кстати а не кинет ли кто ссылкой на архитектуру этих решений (e25k, mX000, ibm p5xx)? особенно интересуют толщины и частоты шин.

IBM уже анонсировала Power7 с 256 процессорами в топовой конфигурации. Посмотрим что Sun запоет после его выпуска.

> короче, железу от сан/ибм сейчас нет никаких альтернатив

+1, у IBM мейнфреймы охлаждаются как холодильники, по 5 процессоров размещены в Multi-Chip модуле, к которому подводятся трубки охлаждения. Представляю сколько понадобится вентиляторов, чтобы такую дуру обдувать в виде кластер x86. Плюс к этому некоторые вещи кластеризовать практически нельзя, тот же Оракл. Производительность RAC'а пока не позволяет это делать.

> IBM уже анонсировала Power7 с 256 процессорами в топовой конфигурации. Посмотрим что Sun запоет после его выпуска.

Пусть сначала выпустит, а там посмотрим, кто что запоет. Интересно, что HP будет делать, когда Интел отправит уже Итаник на свалку истории

>короче, железу от сан/ибм сейчас нет никаких альтернатив

Да ну, Гугль вон, свой сайт на миллионах маленьких PCшек держит. Вроде

> Ну а то что в конфиге IBM было 32 процессора против 64 спарков в новости как всегда скромно умолчали %)

Как вам: два автомобиля - один производства МежДелМаш с 32 двигателями, другой производства Сноракл с 64 двигателями, за одно и то же время первый проехал 100 километров, второй 132.

Но первый все равно быстрее второго в пересчете на один двигатель. Не смешно?

Вы еще про про производительность на ядро вспомните, как эта IBM'овская тетя: https://www.ibm.com/developerworks/mydeveloperworks/blogs/benchmarking/entry/...

В пересчете на один цилиндр тоже быстрее получится :-)

>короче, железу от сан/ибм сейчас нет никаких альтернатив
>Да ну, Гугль вон, свой сайт на миллионах маленьких PCшек держит. Вроде

Сайт сбербанка тоже, как бы, не на SFE25K, однако ж процессинг - на них, родимых.
МТС сайт на венде крутит (конторка, которая их сайт строит и хостит QuantumArt называется), а биллинг, как думаешь на чем? (hint: SFE25K)