Yo.!вывод - я был абсолютно прав утверждая, что трафик у purescale зашкалит за все разумное. это что же за трафик нужно нагенерить, что бы 20 ядер на 75% загрузить ?? для сравнения, оракловому протоколу хватает 5% от одного ядра на трафик 100 mb/s.
из этого теста понять нельзя на сколько эффективен сам протокол, но то что puscale приходиться гонять гигантский трафик - факт неоспоримый. судя по цифрам такому кластеру понадобиться два мейнфрейма на CF ноды, если они попробуют поставить восьмисокетные x86 ноды в попытке побить рекорд RAC в тестах sap-sd.Как обычно, деталей не знаю, но экспертная оценка готова.
Сравнения вы будете делать, когда на том же самом тесте, на примерно тех же самом объёме данных и оборудовании вы поставите другую кластерную систему и получите результаты.
Ну или протестировать RAC в обычном SD тесте.
Дождёмся когда-нубудь? Не верю...

У каждой системы на каждом конкретном тесте всегда будут свои узкие места.
Что до результатов, то смысл там примерно такой.
Чем больший процент изменений в общем кол-ве запросов будет, тем больше будет загрузка CF.
Но кроме приведённой тут информации по:

Part II: Night Processing
No. of balanced accounts/hour: 22,382,000
CPU utilization database servers: 36%
(CF: 75 %, Member 0: 26 %, Member 1: 26 %, Member 2: 26 %, Member 3: 25 %)
CPU utilization application servers: 47%

была ещё и:

Part I: Day Processing
No. of postings to bank accounts/hour: 56,518,000
CPU utilization database servers: 89%
(CF: 59 %, Member 0: 97 %, Member 1: 97 %, Member 2: 97 %, Member 3: 96 %)
CPU utilization application servers: 62%

где мемберы загружены получше.

Поскольку эти результаты были получены в ходе Proof of Concept для какого-то большого банка, то можно предположить, что оборудование было подобрано под приоритетную для заказчика нагрузку (дневную).
Т.е. если надо будет показать хорушую производительность системы в night processing, ну, поставят CF по-мощнее.
Воткнутся в пропускную способность infiniband, уже сейчас есть возможность использовать несколько адаптеров на хосте.
В планах вывести в GA версию кластера, которую использовали в старом внутреннем тесте на 128 мемберах (это если производительности одного активного CF станет не хватать).

Yo.!вывод - я был абсолютно прав утверждая, что трафик у purescale зашкалит за все разумное. это что же за трафик нужно нагенерить, что бы 20 ядер на 75% загрузить ?? для сравнения, оракловому протоколу хватает 5% от одного ядра на трафик 100 mb/s.
из этого теста понять нельзя на сколько эффективен сам протокол, но то что puscale приходиться гонять гигантский трафик - факт неоспоримый. судя по цифрам такому кластеру понадобиться два мейнфрейма на CF ноды, если они попробуют поставить восьмисокетные x86 ноды в попытке побить рекорд RAC в тестах sap-sd.Про "захлебнувшийся" CF:
этот бенчмарк требует, чтоб тест работал не меньше 4-х часов.
Они снизили нагрузку, иначе тест отработал бы быстрее, и сертификат не был бы получен.

Про сильную загрузку cpu на CF: это не только из-за трафика.
Чтоб реализовать работу с мемберами без прерываний, он должен постоянно сканировать определённые участки памяти, куда мемберы напрямую пишут для того, чтоб получить обслуживание.

Ну и важная лицензионная особенность: ядра на CF не лицензируются для DB2.

Alexander RyndinЭто по-прежнему не отвечает на вопрос, почему захлебнулся CF. Я уже ответил на этот вопрос - CF не захлебнулся.
Да, использование cpu на night processing - высокое.
Объясняется это характером нагрузки.
Alexander RyndinПро снижение нагрузки - неубедительно как-то. В сертификате есть строкаавторThe scenario contained 90,000,000 accounts and 1,800,000,000 postingsЕсли бы надо было увеличить длительность теста, то увеличили бы количество account. Где-то тут подвох.Как я уже говорил, это было тестирование под объёмы банка, а не специально для бенчмарка.
Под эти объёмы было подобрано железо.
Потом пришла идея, что параллельно можно и сертификат для бенчмарка получить.

Yo.!Mark Barinstein,

про банк - явно байка какая-то. я не представляю, что должен был быть за банк которого бы интересовал кластер с единственной CF нодой, которая делает весь кластер бесполезной игрушкой, не пригодной в продакшен. ноду эту нужно как минимум дублировать, а на дублирование нуна как минимум +40% cpu, если опираться на бенчмарки sysplex на z/OS. у ibm есть отличный документ Coupling Facility Performance: A Real World Perspective с бенчмарками на тему дублирования CF.
CF на z/os работает на прерываниях, в отличие от CF на pureScale.
Детали можно посмотреть в комментариях здесь:
Industry Benchmark Result for DB2 pureScale: SAP Transaction Banking (TRBK) Benchmark
Там говорят и об этом тесте, и об использовании процессора на CF.
Если кому лень читать - всё то же самое, о чём я говорил.

По поводу дублирования CF:
Нагрузка на первичный CF не возрастёт: CF'ы эти друг с другом не общаются.

Про бесполезную игрушку:
Это что, получается, что все некластерные системы в sap-овских бенчмарках - бесполезные и не пригодные в продакшене?

Yo.!Mark BarinsteinПро бесполезную игрушку:
Это что, получается, что все некластерные системы в sap-овских бенчмарках - бесполезные и не пригодные в продакшене?
конечно бесполезные. оракл и майкрософт на сколько я знаю там даже проверку целостности блоков отключает.Так они делают в tpc тестах, про sap - никогда не слышал.
И это хороший пример читерства со стороны этих компаний.
В db2 даже нет такой возможности - отключить такие проверки.
tpc тесты допускают это, но отключать эти проверки на продакшене это самоубийство.
Из-за этого тесты, в которых разрешены такие вещи, просто вводят в заблуждение людей, ведь в зависимости от типа нагрузки накладные расходы на такие проверки могут достигать 10%.
И никакой кластер от таких ошибок не спасёт.
Поэтому, ваше объяснение бесполезности некластерных систем непонятно.

Yo.!сначала нам рассказывали, что pureScale слизан с z/OS, но как только я показываю как работает в z/OS вы тут же меняете показания, что не совсем как в z/OS.
Я по-прежнему утверждаю, что архитектура взята с z/os.
Это чисто технические отличия в реализации одной и той же архитектуры.
Я не большой знаток z/os, но по-моему, когда там CF'у пишут в память, то возникает железячное прерывание, на которое CF реагирует.
В pureScale нет такой возможности (железо не поддерживает).
Но прицип обмена сообщениями примерно тот же - мембер и CF пишут друг другу в память без прерываний на мембере.
Yo.!вот например в uDAPL я не вижу никаких лупов, с чего вы все таки взяли, что там чего-то лупиться ? потому, что говорят ?
uDAPL здесь не при чём, там ничего и не должно лупиться.
Там примерно так:
С помощью RDMA мембер просто пишет в память CF. И всё, на этом использование RDMA в сторону CF заканчивается.
Чтобы реализовать обмен сообщений без прерываний, CF должен постоянно сканировать память, чтоб узнать, что пришёл запрос на обслуживание.
Я это знаю, потому что да, так говорят разработчики этой системы, и у меня нет оснований им не верить.

Хотя нет, я был неправ.
Сам почитал по своей ссылке про z/os - там тот же самый механизм - постоянный опрос памяти на CF.

Yo.!я на счет бенчмарков Coupling Facility Performance: A Real World Perspective. почему вдруг pureScale сделанный по образу и подобию CF из мира МФ вдруг окажется эффективней в плане дублирования ?
Посмотрите ответ на этот вопрос здесь:
DB2 pureScale Availability - Part 2
Ответ вкратце такой:
там сравнивалось несколько способов дублирования, доступных на Z.
Эти дополнительные более 40% cpu на CF были получены в режиме дублирования (CF-CF), который в pureScale не используется.
Кстати, даже для этого режима есть интересное замечание:
Там же есть ссылка на IDUG Europe 2004, где указывается, что для режима, который используется в pureScale, этот оверхед для CPU на CF равен 1-3%.
Вот использование CPU на мемберах возрастёт, но насколько - зависит от нагрузки.
Там регистрации чтений (а их, таких запросов - очень много), например, не дублируются - в случае отказа первичного CF, вторичный выдаёт команду мемберам скинуть ему эту информацию, и эта операция происходит очень быстро.

Про отсутствии поддержки HARD:
В pureScalе всё же есть DR решение, и оно к тому же active/active:
Configuring geographically dispersed DB2 pureScale clusters
Есть там и возможность делать Q-Replication:
Combining IBM DB2 pureScale with Q Replication for scalability and business continuity

Так что, Yo.!, как системка-то? Рабочая или нет?

Yo.!это конечно здорово, что вы следите за моей перепиской не только тут, но манагер с того блога похоже не самый большой специалист по этой теме.Этот манагер (если вы про Chris Eaton), с которым, я вижу, вы уже подружились в разных переписках, довольно неплохо знает и оракл, и db2, включая pureScale.
По крайней мере, когда я спрашивал у него разные технические детали про pureScale, то он сразу очень подробно отвечал.
Да вы и сами можете погуглить по его ответам на совершенно разные технические детали по db2.

Yo.!во первых, что значит CF-CF ? в parallel sysplex ровно так же как и в pureScale ноды пишут в резервный CF.
во вторых приглядись на что ссылается та презентация - это дублирование кеша, хотя моя цитата относилась именно к блокировкам.Описание system-managed duplexing вы можете найти ближе к концу этой презентации. Там есть описание CF-to-CF link и зачем это там надо.
В pureScale используется что-то похожее на user-managed duplexing, где мемберы шлют параллельные запросы на оба CF, а не первичный CF сам занимается синхронизацией со вторичным, из-за чего потребление cpu на нём значительно растёт.

Yo.!PS. системку надо бы сначала на взрослой конфигурации протестировать, а не на игрушечной. тогда и составим окончание мнение ...90,000,000 счетов и 1,800,000,000 проводок.
56,518,000 проводок в час.
Ну, я бы не сказал, что это такая уж и игрушечная система.
А какие конфигурации вы считаете "взрослыми"?

Yo.!если спец, как объяснить то, что попутал GBP со структурой блокировок ? хотя впрочем и вы похоже не видите разницы...А вы его сами спросите.
Вот, может интересно будет.
DB2 pureScale Overview
Yo.!откройте ту презентацию стр. 28 system-managed ровно так же как и user-managed шлет параллельно запросы на оба CF, по CF-to-CF link лишь lock step делается ...И что?
Ещё раз: тот пример, которую вы привели, относится к тому случаю, когда они решили перейти с external CF на internal CF и проверить, что получится.
Ну и получили то, что получили.
И написали в Lessons learned:
The intended direction to implement only local ICFs in the future has been changed. The
DB2 lock structure is an example of a structure that should be located either in an external
ICF or duplexed for fault tolerance.

В pureScale CF'ы не общаются:
Locking behavior in a DB2 pureScale environment
Lock duplexing is implemented on the local lock manager; when a lock request is granted, the information is sent to the secondary CF before the local lock manager makes use of this lock. There is no communication between the primary and the secondary CF.

Теперь сами подумайте: с какого перепугу на первичном CF должна возрасти нагрузка в такой конфигурации при включении вторичного?