2ggv

Вы случайно не тот самый ggv который иногда появляется в обсуждениях статей на zdnet.ru?
Уж больно похоже.


2Yo!!
Эка вам маркетинг Oracle голову то задурил?
Остороженей надо.

Что касается темы.
Таки ggv все же более прав.

Что есть RAC?
- это софтверный коммутатор, то есть замена аппаратного коммутатора который используется в больших SMP железках ( кажется начиная с 16
узлов ).
Накой он нужен?
Для того чтобы подерживать когерентность кэшей
в случае c RAC - это SGA - узлов.
в случае с SMP(NUMA) - это кэшы процессора

- обмен блоками памяти в SMP( NUMA) архитектурах осушествляется на уровне страниц памяти, а в случае RAC на уровне блоков.


То есть принцип работы почти один и тот же.
Суть в задержках.
Пока задержки на подержание когерентности кэша в SMP(NUMA) архитектурах ниже , чем в случае с RAC.
Это до тех пор пока Oracle не предъявит доказательств обратного .
Пока у него с этим слабо.

Теперь про доказательства.
Я тоже люблю тесты SAP SD 2.
Найдите там максимальный результат.

Fujitsu PRIMEPOWER 2500, 128-way SMP, SPARC64 V 2.08 GHz, 256 KB L1 cache, 4 MB L2 cache
Solaris/Oracle9i
SAPS = 2116330
http://www.sap.com/solutions/benchmark/pdf/cert1305.pdf


Лучший результат в случае RAC.
4 x AlphaServer ES45 Model 2, 4-way SMP, Alpha EV6.8CB (21264C), 8MB L2C
Tru64/Oracle 9i RAC
SAPS= 60,420
http://www.sap.com/solutions/benchmark/pdf/CERT3102.pdf

Разницу в 35 раз говорит сама за себя.
Если бы у RAC было так гладко с масштабируемостью,
то мы бы уже давно увидели результаты на каждом углу, но их нет
и в ближ. будущем не будет насколько я понимаю.

Только не надо говорить про не сравнимые конфигурации.
Я говорю о результатах достигнутых в результате использования технологии.
И лично для меня RAC - это разводилово клиентов на деньги.
Я думаю тоже самое касается и MSSQL кластера.

Yo!! авторТолько не надо говорить про не сравнимые конфигурации.
Я говорю о результатах достигнутых в результате использования технологии.
И лично для меня RAC - это разводилово клиентов на деньги.

ну вот, вы даже сами практически за меня ответ написали, вы сравниваете 16-процесорную систему которую забросили и не развивают уже черт знает сколько и современную 128 процесорную ... вы же не думали что RAC должен был сотварить чудо ??

давайте все же посмотрим что у нас с фактами:
SAP
2x4-way xeon RAC делает db2 на винде
2x4-way IBM eServer p5 Model 570 RAC делает db2 на линух
2x4-way IBM eServer p5 Model 570 RAC проигрывает db2 на aix

TPC-C
RAC на HP Integrity rx5670 Cluster 64P 1,184,893
делает
SQL2005 на HP Integrity Superdome 64P c/s 1,082,203
Oracle на HP Integrity Superdome 1,008,144

OEBS
http://www.oracle.com/apps_benchmark/html/0443A_Report1.html
http://www.oracle.com/apps_benchmark/html/0443A_Report1.html
4х-нодовый кластер вытянул 13020 а smp 15004 при этом ноды у кластера заметно слабее 1.65GHz против 1.9GHz.

т.е. факт в том, что во всех доступных тестах RAC маштабируется как минимум не хуже, в принципе только это я пытался доказать. а вот почему нет RAC-тестов на больших машинах в SAP но есть в TPC-C/TPC-H можно порассуждать/пофантазировать. если у вас есть знания на эту тему было бы интересно услышать.


1. Вы забываете что в случае с RAC-ом есть еще
65 x AlphaServer ES45 Model 2, 4-way SMP, Alpha EV6.8CB (21264C) серверов приложений на которые происходит обработка данных.
В случае с SAP SD обработка данных происходит на сервере.
Так что засчитываем 65 процессоров дополнительно или нет ?

2. Просто с замиранием сердца жду чуда.
Покажите результаты SAP SD Parallel с участием RAC где используются хотя бы 64 процессора на стороне сервера СУБД?
Ну а уж если вы покажите мне 100 проц, то я моему восхищению просто не будет границ.
Итак ссылку в студию.
TPC-C не предлагать - это не серьезно.

3. Тесты OEBS - не подходят.
Пояснить почему?


4. Тесты TPC-C,TPC-H по сравнению с SAP-SD.
4.1. Принципиальное отличие в том что SAP-SD -официальный сайзинг который использую при покупке системы на определенное число пользователей.
То есть тест SAP-SD говорит от том что для определенного числа пользователей SAP необходимо такое -то железо.
В случае с TPC-C это просто синтетический тест, слишком далекий от реальных приложений.
4.2. По условиям теста SAP SD тест прекращается если время отклика становится больше 2сек. В случае с TPC-C время отклика никак не ограничивается. То есть если запрос будет выпольнятся 1 час и успешно выполнится , то это нормально он будет учтен , но как вы понимаете это уже не OLTP cистема.

Yo!!2EugeneS

1. у меня машинка для игр мощней чем этот 4-way alpha, какой смысл сравнивать этого с новейшими спарками ?

2. нет таких, почему не знаю, но судя по тестам TPC их нет не потому что RAC не может. может потому что 9ка так неможет, может результат некрасивый, может по времени отклика не смогли, не знаю, зачем нам гадать ??
вот почему они на древней 9ке гоняют когда вон 10R2 есть, SAP не сертефицировал ?
3. да, было бы интересно.
4. тут полностью согласен но со своей стороны хочу еще раз сказать, мне не интересно гадать. меня интересуют факты. есть тесты от конкретных производителей по которым можно делать относительные выводы, но делать выводы по alpha vs sparc, 3tier vs 2tier, 4-way vs 64-way для меня уже слишком ...

2. То-то и оно. Вот когда будет тогда и будем говорить про масштабируемость RAC-ов.
Насчет 10gR2, он всего 2 дней как официально выложен на сайте.

3. Все очень просто. В этом случае Oracle нельзя проконтролировать.
А что делают капиталисты когда они без котроля ? - Беспредельничают.
То же самое касается всех остальных производителей ПО и железа.

4. Факты гласят.
Приемлемых результатов у Oracle RAC - нет.



Теперь что касается сравнений.
В случае с RAC используется сервера приложений. Не так ли?
То есть если мы хотим сравнивать, то правильней было бы взять
1. SMP сервер БД + сервера приложений
2. сервер БД RAC + сервера приложений

Для случае один существует специально тест SAP SD 3.
Идем, смотрим 2002 год выбираем сервер с 16 проц.
Unisys e-@ction Enterprise Server ES7000, 16-processors, Pentium Xeon 1.6 GHz, 256 KB L2 cache, 12 GB main memory
http://www.sap.com/solutions/benchmark/pdf/cert4902.pdf
SAPS = 97580

Объяснять надо, что 1Ghz Alpha -процессор трудносравним по быстродействию с Pentium Xeon 1.6Ghz?
Что получаемся опять почти 2 каратный проигрыш.
Просто в тестах нет серверов с 16 проц от Sun и IBM, но можно даже не сомневаться что результаты там еще лучше.

Такое сравнение подходит?

Зл0йО масштабируемости RAC. Если "затык" по производительности находится на диске (по термонологии Оракла "в базе данных"), например в виде блокировки, то никакая кластеризация этой проблемы не решит. Если же затык в "instance" (по терминологии Оракла) то она решается RAC'ом. Например если вы ожидаете доступа к неким структкрам данных в памяти, доступ к которым синхронизирован, то наличие N узлов и N "комплектов" данной структуры позволяет вам меньше ждать.

Совершенно верно,
только нужна инфраструктура которая подерживает синхронность или коггерентность этих структур.
В случае с RAC-ом это СACHE FUSION, в случае SMP(NUMA) систем это коммутатор, обеспечивающий когерентность памяти.
Собственно многопроцессорные системы потому так дорого и стоят,
потому что этот коммутатор довольно не простя вещь.
Про задержки я писал.