Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Oracle RAC
onstat-
пропущено...



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

Намек понятен ?

В этом и вопрос, Way4 и другое ПО для карточного процессинга действительно очень плохо масштабируется на кластерах, т.е. требуют для Oracle RAC в разы больше ядер, а значит и больше лицензий, чем при использовании p795?
Потому что для одинакого числа ядер разница между p795 и дешевым железом гораздо больше, чем между лицензиями EE и EE+RAC для всех ядер.


Разница не сколько в RAC а в интеловой шине QPI , она быстрее чем обычный эзернет ,
но медленнее чем инфинибенд.
Чисто теоритически на большом количестве ядер ( 20+) RAC на интеловой платформе может оказаться быстрее чем 80 ядерный интеловый сервер.
За счет минимизации межпроцессного ваимодействия и переноса маршрутизации на инфинибенд свич.

В ИБМовской шине процессорные платы между собой общаются по infiniband ,
без дополнительных PCI прослоек . Архитектура скрывает infiniband под капотом.
То что RAC делает программно , в ИБМе делается аппаратно на уровне IPC.
За счет этого получается теоретический профит.
Теоретический потому, что программисты верхнего уровня вностят самый
большой вклад в тормознутость системы в целом, и обьективно оценить профиты очень тяжело.
31 дек 14, 11:48    [17076232]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Если продолжать сравнение по сабжу , то ИБМ может оказаться в профите
за счет аппаратной виртуализации.
Когда внутри одной железки собрана и база и сервера приложений.

1. Можно тягать процессоры и память между БД и приложениями на лету.
2. По виртуальному эзернет свичу между виртуалками могут бегать джамба фреймы 64 К.
Сетевое оборудование поддерживает только 9К.
3. На сервере можно разметстить прочие приложения например например для офлайновго клиринга
с платежными системами и всякие статистические кубы, фрод мониторинг итд.
4. По мере роста количества транзакций и типов нагрузок
можно динамически перераспределять ресурсы , что бы система была равномерно нагружена по задачам
и в течении периодов, не занимала место в датацентре , не грела в пустую воздух.

Весь технологический цикл процессинга на 10 млн карт с фродоммониторингом,
клирингом, статистическими кубами и дисковым обьемом помещается 42 юнитовую стойку.
Если нужно хранить много истории то в полторы , за счет добавления дисковых полок.

+ вторая стойка резервирования ( стедбаи , тестовые полигоны функциональнойго и стресс тестирования и прочие песочницы).
31 дек 14, 12:18    [17076320]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
ChronSQL
Member

Откуда:
Сообщений: 520
onstat-
Oracle RAC
пропущено...

В этом и вопрос, Way4 и другое ПО для карточного процессинга действительно очень плохо масштабируется на кластерах, т.е. требуют для Oracle RAC в разы больше ядер, а значит и больше лицензий, чем при использовании p795?
Потому что для одинакого числа ядер разница между p795 и дешевым железом гораздо больше, чем между лицензиями EE и EE+RAC для всех ядер.


Разница не сколько в RAC а в интеловой шине QPI , она быстрее чем обычный эзернет ,
но медленнее чем инфинибенд.
Чисто теоритически на большом количестве ядер ( 20+) RAC на интеловой платформе может оказаться быстрее чем 80 ядерный интеловый сервер.
За счет минимизации межпроцессного ваимодействия и переноса маршрутизации на инфинибенд свич.

Чего вы тут такое рассказываете
1. Xeon E7, 3 QPI-links: CPU-1 --> QPI (8 GT/s = 16 GB/sec) --> CPU-2
2. Xeon E3, 20 PCIe-lanes: CPU-1 --> PCIe (16x gen3 = 16 GB/sec) --> Infiniband (12x EDR = 38 GB/sec) --> PCIe (16 GB/sec) --> CPU-1

Во-первых, в Intel-овский CPU есть только 4 встроенных скоростных интерфейса на кристалле DDR, [DMI], PCIe, QPI. Через один link ни войти, ни выйти быстрее, чем 16 GB/sec ничего не может (равно как по QPI, так и по PCIe), так что хоть FDR, хоть EDR по 12x ничего не даст :)

Во-вторых, даже если вы к одному CPU подцепите несколько Infiniband карт, то на Intel CPU бывает максимум 40 PCIe-lanes gen.3 (40 GB/sec), а QPI максимум 3-links (48 GB/sec).

В-третьих, перекодировка пакетов PCIe->Infiniband->PCIe добавляет задержку, а соединение по QPI - прямое из кэша в кэш без перекодировок. Т.е. достойной альтернативой QPI у intel может быть только прямое соединение CPU->PCIe->CPU.

P.S.
К тому же, в системах на Intel:
- QPI позволяет строить ccNUMA с прямым доступом к чужой памяти по указателю с кэш-когерентной AC-семантикой
- Infiniband позволяет добираться до чужой памяти без кэш-когерентности и только через специальные функции, на разных уровнях относящиеся к: verbs/udapl/mpi-2

onstat-
В ИБМовской шине процессорные платы между собой общаются по infiniband ,
без дополнительных PCI прослоек . Архитектура скрывает infiniband под капотом.

А какие скоростные интерфейсы встроены непосредственно в кристалл процессора IBM Power7/8?
31 дек 14, 12:39    [17076367]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
ChronSQL
А какие скоростные интерфейсы встроены непосредственно в кристалл процессора IBM Power7/8?


тынц
Картинка с другого сайта.

соединяются каждый с каждым или попарно какждая пара с каждой
Картинка с другого сайта.

В зависимости от количества процессорных блоков в сервере.
31 дек 14, 13:37    [17076503]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
Yo.!
Guest
onstat-
С точки зрения инвестиций выгоднее купть дорогое железо с аппаратным
резервированием и меньше софт лицензий.
Чем дешевое железо и больш софт е лицензий за теже самые деньги.

Намек понятен ?

мне нет. вот беру сопоставимые системы из SAP benchmarks
740250 saps на 6 x Sun Fire X4800 M2, 8 processors / 80 cores Xeon Processor E7-8870, 2.40 GHz
VS
688630 saps IBM Power 795, 32 Processors / 256 Cores POWER7, 4 Ghz

можно на этом, конкретном примере показать как у вас p795 оказался дешевле, учитывая что оракловый софт с SAP идет бесплатно ?
31 дек 14, 13:52    [17076550]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-
С точки зрения инвестиций выгоднее купть дорогое железо с аппаратным
резервированием и меньше софт лицензий.
Чем дешевое железо и больш софт е лицензий за теже самые деньги.

Намек понятен ?

мне нет. вот беру сопоставимые системы из SAP benchmarks
740250 saps на 6 x Sun Fire X4800 M2, 8 processors / 80 cores Xeon Processor E7-8870, 2.40 GHz
VS
688630 saps IBM Power 795, 32 Processors / 256 Cores POWER7, 4 Ghz

можно на этом, конкретном примере показать как у вас p795 оказался дешевле, учитывая что оракловый софт с SAP идет бесплатно ?


Что можно еще впихнуть на 6 x Sun Fire, не переделывая систему?

А внутрь IBM Power 795, можно на лету подвинуть SAP по ядрам и памяти и
запихнуть туда еще что то, например какакую нибудь самопальную аналитику ,
если SAP не используется на полную мощьность и оборудования в данный момент простаивает.
31 дек 14, 14:02    [17076596]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
Yo.!
Guest
onstat-
Что можно еще впихнуть на 6 x Sun Fire, не переделывая систему?

ну весь тот современный софт, что на p795 гонять бессмысленно. например биг дата, вместо самопальной аналитики
31 дек 14, 14:15    [17076647]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
onstat-
Yo.!
пропущено...

мне нет. вот беру сопоставимые системы из SAP benchmarks
740250 saps на 6 x Sun Fire X4800 M2, 8 processors / 80 cores Xeon Processor E7-8870, 2.40 GHz
VS
688630 saps IBM Power 795, 32 Processors / 256 Cores POWER7, 4 Ghz

можно на этом, конкретном примере показать как у вас p795 оказался дешевле, учитывая что оракловый софт с SAP идет бесплатно ?


Что можно еще впихнуть на 6 x Sun Fire, не переделывая систему?

А внутрь IBM Power 795, можно на лету подвинуть SAP по ядрам и памяти и
запихнуть туда еще что то, например какакую нибудь самопальную аналитику ,
если SAP не используется на полную мощьность и оборудования в данный момент простаивает.
Ну так ведь необязательно ставить сразу все 6 x Sun Fire X4800 M2. Покупаем постепенно. А на разницу покупаем между стоимостью (6 x Sun Fire X4800 M2) vs (IBM Power 795) покупаем еще (12 x Sun Fire X4800 M2) :))
31 дек 14, 14:24    [17076702]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Alexander Ryndin
onstat-
пропущено...


Что можно еще впихнуть на 6 x Sun Fire, не переделывая систему?

А внутрь IBM Power 795, можно на лету подвинуть SAP по ядрам и памяти и
запихнуть туда еще что то, например какакую нибудь самопальную аналитику ,
если SAP не используется на полную мощьность и оборудования в данный момент простаивает.
Ну так ведь необязательно ставить сразу все 6 x Sun Fire X4800 M2. Покупаем постепенно. А на разницу покупаем между стоимостью (6 x Sun Fire X4800 M2) vs (IBM Power 795) покупаем еще (12 x Sun Fire X4800 M2) :))



Я имел ввиду 80 cores Xeon Processor E7-8870, 2.40 GHz.

Как от него отрезать десяток ядер для какой нибудь срочной задачи поставленной менеджментом.
31 дек 14, 14:29    [17076728]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Alexander Ryndin
onstat-
пропущено...


Что можно еще впихнуть на 6 x Sun Fire, не переделывая систему?

А внутрь IBM Power 795, можно на лету подвинуть SAP по ядрам и памяти и
запихнуть туда еще что то, например какакую нибудь самопальную аналитику ,
если SAP не используется на полную мощьность и оборудования в данный момент простаивает.
Ну так ведь необязательно ставить сразу все 6 x Sun Fire X4800 M2. Покупаем постепенно. А на разницу покупаем между стоимостью (6 x Sun Fire X4800 M2) vs (IBM Power 795) покупаем еще (12 x Sun Fire X4800 M2) :))


IBM можно тоже не покупать сразу а докупить процессоры и память потом,
или купить польность , но активировать ресурсы по неоьходимости.
Можно купить 256 ядер, а активировать 64, размазав инвестиции на период.
На месяц( реально до перзагрузки какой либо из виртуальных машин).
можно однократно бесплатно взять активацию процессоров и памяти на все купленное.
За это время оплатить перманентную активацию и получить чесный код ,
или купить у ИБМ временную активацию по истечении которой ( перезагрузки виртуальной машины )
ресурсы снова станут не активными.
31 дек 14, 14:38    [17076751]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-
Что можно еще впихнуть на 6 x Sun Fire, не переделывая систему?

ну весь тот современный софт, что на p795 гонять бессмысленно. например биг дата, вместо самопальной аналитики


Я не вижу проблем запихнуть в новый LPAR имеющейся 795 машины рядом LPARами SAPа Power Linux & hadoop.
Если на уже имеющемся сревере есть гуляющие ресурсы.
А 20% есть практически всегда....

Как минуимум стартап можно развернуть и оценить целесобразность развития направления
для компании не ввязываять в бюджетный процесс , тендера итд итп....
31 дек 14, 14:55    [17076805]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
Yo.!
Guest
onstat-
Я не вижу проблем запихнуть в новый LPAR имеющейся 795 машины рядом LPARами SAPа Power Linux & hadoop.

это потому, что вы не увидели, что в документе речь идет о кластере. идеология биг дата - прямая противоположность p795. hadoop с его map-reduce это жутко не неэффективный кластер, который на все и вся фигачит фулскан. вся соль в том, что имея тучу ресурсов, всем пофигу на эту неоптимальность, все радуются конечному результату, пусть и не оптимального, за то очень очень дешево. ставить hadoop на p795 попросту не имеет смысла.
по моим расчетам тот p795 стоил $12 млн, т.е. разница с 6х Sun Fire X4800 M2 около $11 млн. с такой разницей на каждую задачу можно хоть новый кластер собирать, а старый в интернат отдавать, детям.
31 дек 14, 15:11    [17076869]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
ChronSQL
Member

Откуда:
Сообщений: 520
onstat-
+
ChronSQL
А какие скоростные интерфейсы встроены непосредственно в кристалл процессора IBM Power7/8?


тынц
Картинка с другого сайта.



По вашему тынцу написано: "Each chip features 5 10-B SMP links that supports SMP operation of up to 32 sockets", т.е. 32 CPU соединяются между собой по SMP-link-у, в итоге имея 32*8=256 ядер, т.е. 1024 потока, что и есть p795.
А можно подробней о "В ИБМовской шине процессорные платы между собой общаются по infiniband", что-то ни слова о Infiniband по вашей ссылке?

На вашем рисунке видно, что IBM Power7 не имеет встроенного в кристалл Infiniband, но имеет 4 скоростных интерфейса: DDR, SMP, off-MCM link, I/O.

А вот рисунок где показано, что Infiniband в Power7 подключается так: CPU --> I/O --> I/O Hub --> PCI-Bridge --> PCIe --> Infiniband (PCI-Device)
И только Power8 избавился от проприетарных GX-Bus и I/O Bridge и наконец имеет встроенный в кристалл процессора контроллер PCIe gen3, т.е. тут Infiniband подключается так: CPU --> PCIe --> Infiniband

Картинка с другого сайта.

Картинка с другого сайта.
31 дек 14, 15:40    [17076941]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
ChronSQL
Member

Откуда:
Сообщений: 520
PS
Причем интересное замечание, что если представить 32 сокета в виде матрицы 4 х 8, то все сокеты в каждой строчке соединены между собой кольцевой шиной, и все сокеты в каждом столбце соединены между собой кольцевой шиной.
Кто-нибудь знает, что это за топология и для каких задач она выгодна?

Картинка с другого сайта.
31 дек 14, 15:52    [17076982]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
ChronSQL
onstat-
+
пропущено...


тынц
Картинка с другого сайта.



По вашему тынцу написано: "Each chip features 5 10-B SMP links that supports SMP operation of up to 32 sockets", т.е. 32 CPU соединяются между собой по SMP-link-у, в итоге имея 32*8=256 ядер, т.е. 1024 потока, что и есть p795.
А можно подробней о "В ИБМовской шине процессорные платы между собой общаются по infiniband", что-то ни слова о Infiniband по вашей ссылке?


Прошу прощения, я не нашел в открытых источниках информацию, однозначно отвечающую на ваш вопрос.
Когда то мимо меня проскакивала презентация что конкретно
в этих машинах
для
Inter-node buses (4 enclosures) 158.02 Gbps

infiniband, есть транспортным протоколом для SMP-link ов,
для взаимодействия процессорных плат находящихся в разных цеках.
31 дек 14, 16:24    [17077113]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
ChronSQL
Member

Откуда:
Сообщений: 520
onstat-
ChronSQL
пропущено...


По вашему тынцу написано: "Each chip features 5 10-B SMP links that supports SMP operation of up to 32 sockets", т.е. 32 CPU соединяются между собой по SMP-link-у, в итоге имея 32*8=256 ядер, т.е. 1024 потока, что и есть p795.
А можно подробней о "В ИБМовской шине процессорные платы между собой общаются по infiniband", что-то ни слова о Infiniband по вашей ссылке?


Прошу прощения, я не нашел в открытых источниках информацию, однозначно отвечающую на ваш вопрос.
Когда то мимо меня проскакивала презентация что конкретно
в этих машинах
для
Inter-node buses (4 enclosures) 158.02 Gbps

infiniband, есть транспортным протоколом для SMP-link ов,
для взаимодействия процессорных плат находящихся в разных цеках.

А примерно насколько уверены в том, что помните правильно и что автор той презентации не ошибся, 20 / 50 / 90%?
31 дек 14, 16:54    [17077245]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
ChronSQL
onstat-
пропущено...


Прошу прощения, я не нашел в открытых источниках информацию, однозначно отвечающую на ваш вопрос.
Когда то мимо меня проскакивала презентация что конкретно
в этих машинах
для
Inter-node buses (4 enclosures) 158.02 Gbps

infiniband, есть транспортным протоколом для SMP-link ов,
для взаимодействия процессорных плат находящихся в разных цеках.

А примерно насколько уверены в том, что помните правильно и что автор той презентации не ошибся, 20 / 50 / 90%?


Автор может и ошибся , но документация врядли ошибается в числе 158.02 Gbps
31 дек 14, 17:08    [17077310]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
ChronSQL
Member

Откуда:
Сообщений: 520
onstat-
ChronSQL
пропущено...

А примерно насколько уверены в том, что помните правильно и что автор той презентации не ошибся, 20 / 50 / 90%?


Автор может и ошибся , но документация врядли ошибается в числе 158.02 Gbps

Судя по всему это суммарная пропускная способность нескольких линков между двумя процессорными платами (nodes), а как вы понимаете в топологии "тор" несколько линков - это не так уж и много 158/8 = 20 GB/sec (по сравнению с 40 GB/sec в PCIe gen3 40 lane, и 48 GB/sec в QPI 3 links).
31 дек 14, 17:21    [17077343]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
onstat-
Member

Откуда:
Сообщений: 6941
ChronSQL
onstat-
пропущено...


Автор может и ошибся , но документация врядли ошибается в числе 158.02 Gbps

Судя по всему это суммарная пропускная способность нескольких линков между двумя процессорными платами (nodes), а как вы понимаете в топологии "тор" несколько линков - это не так уж и много 158/8 = 20 GB/sec (по сравнению с 40 GB/sec в PCIe gen3 40 lane, и 48 GB/sec в QPI 3 links).


Правильно , речь ведь не в количестве, а в скорости взаимодействия нод.
p 47. Figure 2-9 SMP Cables installation order
Каждый с соединяется с каждым по шине 158.02 Gbps.


Чуть выше на странице 43 в таблице скорости взаимодействия по кешам , памяти, шинам ввода вывода ........
5 янв 15, 11:19    [17086258]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
ChronSQL
Member

Откуда:
Сообщений: 520
onstat-
ChronSQL
пропущено...

Судя по всему это суммарная пропускная способность нескольких линков между двумя процессорными платами (nodes), а как вы понимаете в топологии "тор" несколько линков - это не так уж и много 158/8 = 20 GB/sec (по сравнению с 40 GB/sec в PCIe gen3 40 lane, и 48 GB/sec в QPI 3 links).


Правильно , речь ведь не в количестве, а в скорости взаимодействия нод.
p 47. Figure 2-9 SMP Cables installation order
Каждый с соединяется с каждым по шине 158.02 Gbps.


Чуть выше на странице 43 в таблице скорости взаимодействия по кешам , памяти, шинам ввода вывода ........

Да, вижу, что ноды в IBM p770/780 соединяются каждая с каждой на странице 47.
На странице 43: скорость взаимодействия между нодами (Inter-node buses (4 enclosures)) 158.02 Gbps = 20 GB/sec, и ещё более впечатляющая скорость взаимодействия внутри нод (Intra-node buses (4 enclosures)) 415.74 Gbps = 52 GB/sec.
Но важно понять, что понимается под этой скоростью?
1. скорость всех линков одной ноды
2. или скорость только SMP-линков между двумя любыми нодами
3. или скорость всех SMP-линков одного процессора
4. или же скорость одного SMP-линка


1. Если мы сравниваем скорость всех линков одной ноды (8 CPU), то совсем честно с Intel сравнивать не получится потому, что у Intel в ccNUMA больше 8 CPU over QPI просто не бывает, т.е. просто не бывает больше одной кэш-когерентной ноды у Intel - и это их косяк.
Но если в Intel несколько нод соединить по PCIe/Infiniband, а считать будем по PCIe, т.к. он будет непреодолимым ограничением, то из одной ноде в Intel из 8 CPU можно вывести 8*40=320 линии PCIe gen3, каждая по 1 GB/sec. Т.е. общая скорость межнодового соединения всех линков одной ноды в Intel равна 2560 Gbps = 320 GB/sec.

2. Если же в p770/p780 имеется ввиду скорость только линков между двумя любыми нодами, то суммарная скорость от 1 ноды к каждой из 3х была бы равна: 158.02*3 Gbps = 474.06 Gbps = 60 GB/sec, что все таки меньше, чем мы могли бы сделать у Intel.

3. Если же в p770/780 понимается скорость всех линков одного процессора внутри ноды равная 415.74 Gbps = 52 GB/sec, то что же тогда изображено в обведенных красными овалами на рисунке по вашей же ссылке на странице 27?
Если подсчитать: 2.46 Gb/s * 2 + 3.25 Gb/s * 3 = 14.67 Gb/s (то ли гигабайт, толи гигабит). Что это за число?
Если сделать нехитрые вычисления:
2.464 Gb/s * 8 CPU * 8 bit_per_byte * 1 (в одну сторону) = 157.696 Gbps - очень похожее на 158.02 Gbps из таблицы.
3.248 Gb/s * 8 CPU * 8 bit_per_byte * 2 (в каждую сторону) = 415,744 Gbps - очень похоже на 415.74 Gbps из таблицы.

Т.е. действительно, это суммарная пропускная способность всех линков в одной ноде:
- 157.696 Gbps - суммарная выходящая скорость наружу из ноды, по 52.56 Gbps с каждой нодой. И как мы считали выше, у Intel-а по QPI межнодовой нет, но можно создать по PCIe межнодовую суммарную скорость: 2560 Gbps = 320 GB/sec.

- 415.74 Gbps - суммарная скорость всех SMP-линков Х всех CPU внутри ноды. Если сравнить с Intel на 8 CPU, получаем 3 QPI-links * 8 CPU * 16 GTs(16 GB/s) = 3*8*16 = 384 GB/sec = 3072 Gbps.

4. Скорость одного SMP-link в Power7 для систем p770/780 показана на картинке.
Картинка с другого сайта.
5 янв 15, 20:03    [17087399]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
Гимилькон бен Гамилькар Магонид
Member [заблокирован]

Откуда:
Сообщений: 1451
Oracle RAC,

Для процессинга не нужен RAC. Достаточно обычного SN кластера. На одном сервере, видимо, сбербанку удобней.
7 янв 15, 22:07    [17092807]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
Гимилькон бен Гамилькар Магонид
Member [заблокирован]

Откуда:
Сообщений: 1451
И взаимодействие между нодами ненужно, если все операции по счету клиента лежат на одной ноде.
7 янв 15, 22:09    [17092816]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
Гимилькон бен Гамилькар Магонид
Member [заблокирован]

Откуда:
Сообщений: 1451
И вообще, ничего ненужно. Но на ИБМе круче, разумеется, да и по цене примерно столько же, сколько без него.
7 янв 15, 22:10    [17092820]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
oraway
Guest
Oracle RAC
Подскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC?


Складывалась скверная ситуация: с WAY4 могла наступить полная задница, как раз во время прямой трансляции выступления президента В.Путина сегодня днём!

Переключиться на Stand-in и откатить патч в дневное время у нас почти невозможно, поскольку резервная база не потянет высокую нагрузку, такое возможно лишь ночью (Stand-in как минимум в 2 раза менее мощный, поскольку он, в отличие от основной базы, почему-то был сделан не в RAC конфигурации по воле архитекторов).

Похоже, что основная оракловая база главного процессинга страны таки стоит RAC-ом....и видимо на POWER 795-ых
11 янв 15, 21:22    [17103452]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
oraway
Oracle RAC
Подскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC?


Складывалась скверная ситуация: с WAY4 могла наступить полная задница, как раз во время прямой трансляции выступления президента В.Путина сегодня днём!

Переключиться на Stand-in и откатить патч в дневное время у нас почти невозможно, поскольку резервная база не потянет высокую нагрузку, такое возможно лишь ночью (Stand-in как минимум в 2 раза менее мощный, поскольку он, в отличие от основной базы, почему-то был сделан не в RAC конфигурации по воле архитекторов).

Похоже, что основная оракловая база главного процессинга страны таки стоит RAC-ом....и видимо на POWER 795-ых
а чем бы тут рак помог?
11 янв 15, 22:23    [17103582]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить