|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Подскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Можно ли на пальцах это как-то объяснить? По идее же можно разнести клиентов по разным нодам и обрабатывать их независимо, ведь только со счетов клиентов деньги списываются моментально, а все остальные операции делают отложено во времени, в фоне, большими порциями, что несколько уменьшает требования к интерконекту нод кластера. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 12:28 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RACПодскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Можно ли на пальцах это как-то объяснить? По идее же можно разнести клиентов по разным нодам и обрабатывать их независимо, ведь только со счетов клиентов деньги списываются моментально, а все остальные операции делают отложено во времени, в фоне, большими порциями, что несколько уменьшает требования к интерконекту нод кластера. "разнести клиентов по разным нодам и обрабатывать их независимо" в Oracle RAC это независимые дисковые системы будут обрабатывать? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 15:40 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Ну и вопрос миллионов долларов не раскрыт. Подозреваю, что софт сопоставим со стоимостью железа, а возможно, что и дороже. Поддержка же и прибыл/ущерб для бизнеса - еще больше. Т.ч. цена железа на общем фоне не особо значительна. Скорее всего. Когда внедряли WMS (управление складом), вставал вопрос о необходимости закрытия склада на инвентаризацию. Владелец бизнеса сказал просто "1 день простоя склада - убыток 1 миллион долларов, если консалтер готов оплатит - без проблем, можете и на год закрыть" ))) /почти дословно, сам на совещании присутствовал/ ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 16:06 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevВладелец бизнеса сказал просто "1 день простоя склада - убыток 1 миллион долларов, Это про склад, который можно инвентаризовать за день? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 16:09 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Ivan DurakOracle RACПодскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Можно ли на пальцах это как-то объяснить? По идее же можно разнести клиентов по разным нодам и обрабатывать их независимо, ведь только со счетов клиентов деньги списываются моментально, а все остальные операции делают отложено во времени, в фоне, большими порциями, что несколько уменьшает требования к интерконекту нод кластера. "разнести клиентов по разным нодам и обрабатывать их независимо" в Oracle RAC это независимые дисковые системы будут обрабатывать? Наприме, да. Разные ноды будут писать данные для разных клиентов в разные партиции, расположенные на физически разных дисковых массивах - ASM/Exadata позволяют это делать. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 16:18 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevНу и вопрос миллионов долларов не раскрыт. Подозреваю, что софт сопоставим со стоимостью железа, а возможно, что и дороже. Поддержка же и прибыл/ущерб для бизнеса - еще больше. Т.ч. цена железа на общем фоне не особо значительна. Скорее всего. Когда внедряли WMS (управление складом), вставал вопрос о необходимости закрытия склада на инвентаризацию. Владелец бизнеса сказал просто "1 день простоя склада - убыток 1 миллион долларов, если консалтер готов оплатит - без проблем, можете и на год закрыть" ))) /почти дословно, сам на совещании присутствовал/ А где гарантия, что вероятность того, что накроется 1 большой сервер меньше, чем накроются одновременно 2 сервера поменьше. Если у RAC накроется 1 сервер то все не остановится, только тормозить начнет, а "владелец бизнеса" ничего не говорил про скорость обработки, а говорил только про полный простой :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 16:21 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RAC...Если у RAC накроется... Это из теории или из практики? ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 16:36 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevOracle RAC...Если у RAC накроется... Это из теории или из практики? ))) Больше из теории :) Сейчас Александр Рындин придет и расскажет что на практике всё ещё лучше ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 16:59 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RACА где гарантия, что вероятность того, что накроется 1 большой сервер меньше, чем накроются одновременно 2 сервера поменьше.Ну, собственно, одна из фишек больших ящиков - возможность заменять и добавлять почти всё и вся без остановки приложений. Так что вероятность одновременного выхода всех критичных узлов большого ящика может быть и меньше, чем у отдельных железок. P.S. Читал историю, когда точкой отказа оказался проводок в стойке, даже не участвовавший в обработке данных, но, надо полагать, по таким случаям делают выводы. И организационные, и технические. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 17:10 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
softwarerЭто про склад, который можно инвентаризовать за день? Нет, просто в договоре обещали остановить склад на 2 дня (выходные), а по факту кладовщики в данный срок не укладывались. Вроде еще +3 дня хотели, ну и инвентаризировать нужно было не все, а только некоторые группы товаров. По большинству групп товаров расхождения были не критичны для функционирования системы (данные по остаткам брались из пред.системы) на момент старта. А некоторые группа нужно было инвентаризировать. Т.к. в пред. системы данные были не полные и недостаточные для работы WMS. С остановкой склада там вообще все было очень сложно (((. Заказчик предлагал только 2-е конкретные даты - паузу в новый год + еще какую-то дата летом. Пропуск "окна" и все внедрение автоматом продлевалось на полгода. В принципе это и была главная проблема на проекте. Т.к. в договорные сроки не укладывались с самого начала (как обычно), а профекапить на полгода уже сильно. А промежуточных вариантов (профекапить на 1-2 месяца) не было ))). Вроде оборот по складу шел на миллиарды долларов. Т.ч. цифра наверное реальная. Я это к тому, что стоимость железа при таких проектах может быть совсем не главным фактором. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 18:32 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RACIvan Durakпропущено... "разнести клиентов по разным нодам и обрабатывать их независимо" в Oracle RAC это независимые дисковые системы будут обрабатывать? Наприме, да. Разные ноды будут писать данные для разных клиентов в разные партиции, расположенные на физически разных дисковых массивах - ASM/Exadata позволяют это делать. На каких разных если это shared disk по-любому? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 18:38 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
и да Exadata сама "за миллионы долларов" перевалит легко ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 18:43 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Basil A. SidorovOracle RACА где гарантия, что вероятность того, что накроется 1 большой сервер меньше, чем накроются одновременно 2 сервера поменьше.Ну, собственно, одна из фишек больших ящиков - возможность заменять и добавлять почти всё и вся без остановки приложений. Так что вероятность одновременного выхода всех критичных узлов большого ящика может быть и меньше, чем у отдельных железок. P.S. Читал историю, когда точкой отказа оказался проводок в стойке, даже не участвовавший в обработке данных, но, надо полагать, по таким случаям делают выводы. И организационные, и технические. Вы про Hot Swap и Hot Plug, а Hot Swap умеет ловить произвольные сбои и продолжать работу без остановки если, например, сгорел один из CPU? Если да, то если к примеру на 2х узловом RAC на одной ноде упадет проц, а на второй ноде упадет сетевая карта, то обе ноды RAC накроются, а если на 1 большом ящике сгорит один из процов и одна из сетевых карт, то работа продолжится. Вопрос, умеет ли железо больших ящиков, например, IBM p795 и база Oracle безостановочно разрешать такие кейсы с выходом из строя железок? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 18:46 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Ivan DurakOracle RACпропущено... Наприме, да. Разные ноды будут писать данные для разных клиентов в разные партиции, расположенные на физически разных дисковых массивах - ASM/Exadata позволяют это делать. На каких разных если это shared disk по-любому? И? Продолжите мысль, и поэтому нельзя разнести данные по разным партициям, или нельзя партиции разнести по разным tablespace-ам, которые мы разместим на разных физических-массивах/келлах-Exadata? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 18:50 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RACHot Swap умеет ловить произвольные сбои и продолжать работу без остановки если, например, сгорел один из CPU?Я не настолько глубоко интересовался вопросом :-))) Технически, даже на писюках, со времён i486, появилась возможность контролировать работу одного процессора другим. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 18:58 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Вы занимаетесь придумыванием сферической архитектуры для сферического банка в вакууме клиентских счетов? Ваш вопрос хорошо бы задать вендору используемой прикладной системы: 1. Поддерживает ли он (вендор) кластер вообще 2. Если поддерживает, что он рекомендует 3. Ну и по деталям реализации архитектуры, тоже, хорошо бы смотреть _конкретную_ систему, а не сферическую. 4. Сайзинг под конкретную систему, тоже хорошо бы, что бы делал вендор. IMHO etc. Что используется в Сбере не знаю, а тем более структуры их БД. Там не работаю. Подозреваю, что ИТ директор Сбера на данном форуме, что бы ответить на Ваш вопрос "почему толстая железяка, а не кластер из PCков" ))), не тусуется. IMHO А то топик выглядит: "...как бы хорошо было, если бы вдруг от дома провести подземный ход или чрез пруд выстроить каменный мост, на котором бы были по обеим сторонам лавки, и чтобы в них сидели купцы и продавали разные мелкие товары, нужные для крестьян... " ( C ) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 19:12 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Как и стоило подозревать, быстрым поиском по google находится, что OpenWay еще в 2005 г. заявил, что RAC поддерживает. Почему для _конкретных_ банка, была выбрана _конкретно_ такая конфигурация, наверное нужно задавать людям, которые это решение принимали. Или смотреть проектные документы (если они есть и к ним есть доступ). IMHO ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 19:16 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
У них, наверное, и стендая нэма, судя по нашумевшему случаю:) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2014, 19:35 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevКак и стоило подозревать, быстрым поиском по google находится, что OpenWay еще в 2005 г. заявил, что RAC поддерживает.Видел я систему, которая тоже заявляла, что кластер поддерживается. Но означало это лишь то, что оно там запускется. А тесты показали, что на кластере из двух машин оно работает существенно медленнее, чем на одной такой же :) А насчет Way4 - пару лет назад после известного сбоя на Хабре кто-то заявлял, что Way4 для RAC пока не адаптировано. Кто тут врет - я не знаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2014, 16:52 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RACЕсли да, то если к примеру на 2х узловом RAC на одной ноде упадет проц, а на второй ноде упадет сетевая карта, то обе ноды RAC накроются, а если на 1 большом ящике сгорит один из процов и одна из сетевых карт, то работа продолжится. Вопрос, умеет ли железо больших ящиков, например, IBM p795 и база Oracle безостановочно разрешать такие кейсы с выходом из строя железок? Даже ИБМовское железо умеет добавлять процессры в операционку ( AIX) на лету и и давать команду ораклу на пересчет логичских процессоров. Сетевые адаптеры и даже сетевые маршруты по свичам резервируются на уровне виртуальной среды , либо непосредственно в ОС . В более дешевом железе процы нельзя заменить на лету, нужно останавливать сервер. Можно даже сделать так, что оракл будет думать что у него тоже количество процессоров , а реально работать будет меньше или больше, но это не чесно с точки зрения оракловых лицензий. В бизнес время процессоры отдать в ОЛТП , а ночью перекинуть виртуалку с другим ораклом , который грузит кубы в варехауз. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2014, 19:30 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
onstat-Oracle RACЕсли да, то если к примеру на 2х узловом RAC на одной ноде упадет проц, а на второй ноде упадет сетевая карта, то обе ноды RAC накроются, а если на 1 большом ящике сгорит один из процов и одна из сетевых карт, то работа продолжится. Вопрос, умеет ли железо больших ящиков, например, IBM p795 и база Oracle безостановочно разрешать такие кейсы с выходом из строя железок? Даже ИБМовское железо умеет добавлять процессры в операционку ( AIX) на лету и и давать команду ораклу на пересчет логичских процессоров. Сетевые адаптеры и даже сетевые маршруты по свичам резервируются на уровне виртуальной среды , либо непосредственно в ОС . В более дешевом железе процы нельзя заменить на лету, нужно останавливать сервер. Можно даже сделать так, что оракл будет думать что у него тоже количество процессоров , а реально работать будет меньше или больше, но это не чесно с точки зрения оракловых лицензий. В бизнес время процессоры отдать в ОЛТП , а ночью перекинуть виртуалку с другим ораклом , который грузит кубы в варехауз. Ок, добавить можно. А заменить на лету, т.е. не останавливая Oracle, может ли: Oracle автоматически понять что проц сгорел, используя db/redo/undo откатить все текущие транзакции завязанные на этот проц, продолжить работу без остановки? И почему " Даже ИБМовское", т.е. даже ИБМовское может, а Intel-вское и подавно может это? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2014, 19:37 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevКак и стоило подозревать, быстрым поиском по google находится, что OpenWay еще в 2005 г. заявил, что RAC поддерживает. Почему для _конкретных_ банка, была выбрана _конкретно_ такая конфигурация, наверное нужно задавать людям, которые это решение принимали. Или смотреть проектные документы (если они есть и к ним есть доступ). IMHO IMHO Конкретно такая конфигурация была выбрана для резервирования системы в другом ЦОД. Внутри одного ЦОД системы не резервировались. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2014, 19:37 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RAConstat-пропущено... Даже ИБМовское железо умеет добавлять процессры в операционку ( AIX) на лету и и давать команду ораклу на пересчет логичских процессоров. Сетевые адаптеры и даже сетевые маршруты по свичам резервируются на уровне виртуальной среды , либо непосредственно в ОС . В более дешевом железе процы нельзя заменить на лету, нужно останавливать сервер. Можно даже сделать так, что оракл будет думать что у него тоже количество процессоров , а реально работать будет меньше или больше, но это не чесно с точки зрения оракловых лицензий. В бизнес время процессоры отдать в ОЛТП , а ночью перекинуть виртуалку с другим ораклом , который грузит кубы в варехауз. Ок, добавить можно. А заменить на лету, т.е. не останавливая Oracle, может ли: Oracle автоматически понять что проц сгорел, используя db/redo/undo откатить все текущие транзакции завязанные на этот проц, продолжить работу без остановки? И почему " Даже ИБМовское", т.е. даже ИБМовское может, а Intel-вское и подавно может это? Я не знаю на счет интеловского . я сначала думал написать о простом ИБМовском железе Которое в десятки раз дешевле 795 сервера. Оно тоже может добавлять удалять процессоры в операционке на лету. Но там нельзя заменить процессор не выключая питания. А В 795 машине можно. Транзакции на проц не завязаны. Хай Энд оборудование использует привентивную замену компонент. Если система почуствует, что процессору плохо ( локальный перегрев какой то области чипа) , то процессор должен быть выведен из эксплуатации до того как сгорит. Я работаю с Power ситемам более 10 лет , ни разу не сталкивался со сгоревшим процессором. Сталкивался с принудительным выведением памяти из эксплуатации , когда у операционки , становится на 8 гиг меньше оперативной памяти. При этом все продолжает работать как и работало. Оракл ничего не заметил. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2014, 19:56 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RACПодскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Можно ли на пальцах это как-то объяснить? По идее же можно разнести клиентов по разным нодам и обрабатывать их независимо, ведь только со счетов клиентов деньги списываются моментально, а все остальные операции делают отложено во времени, в фоне, большими порциями, что несколько уменьшает требования к интерконекту нод кластера. С точки зрения инвестиций выгоднее купть дорогое железо с аппаратным резервированием и меньше софт лицензий. Чем дешевое железо и больш софт е лицензий за теже самые деньги. Намек понятен ? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2014, 20:40 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
onstat-Oracle RACПодскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Можно ли на пальцах это как-то объяснить? По идее же можно разнести клиентов по разным нодам и обрабатывать их независимо, ведь только со счетов клиентов деньги списываются моментально, а все остальные операции делают отложено во времени, в фоне, большими порциями, что несколько уменьшает требования к интерконекту нод кластера. С точки зрения инвестиций выгоднее купть дорогое железо с аппаратным резервированием и меньше софт лицензий. Чем дешевое железо и больш софт е лицензий за теже самые деньги. Намек понятен ? В этом и вопрос, Way4 и другое ПО для карточного процессинга действительно очень плохо масштабируется на кластерах, т.е. требуют для Oracle RAC в разы больше ядер, а значит и больше лицензий, чем при использовании p795? Потому что для одинакого числа ядер разница между p795 и дешевым железом гораздо больше, чем между лицензиями EE и EE+RAC для всех ядер. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2014, 20:58 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RAConstat-пропущено... С точки зрения инвестиций выгоднее купть дорогое железо с аппаратным резервированием и меньше софт лицензий. Чем дешевое железо и больш софт е лицензий за теже самые деньги. Намек понятен ? В этом и вопрос, Way4 и другое ПО для карточного процессинга действительно очень плохо масштабируется на кластерах, т.е. требуют для Oracle RAC в разы больше ядер, а значит и больше лицензий, чем при использовании p795? Потому что для одинакого числа ядер разница между p795 и дешевым железом гораздо больше, чем между лицензиями EE и EE+RAC для всех ядер. Разница не сколько в RAC а в интеловой шине QPI , она быстрее чем обычный эзернет , но медленнее чем инфинибенд. Чисто теоритически на большом количестве ядер ( 20+) RAC на интеловой платформе может оказаться быстрее чем 80 ядерный интеловый сервер. За счет минимизации межпроцессного ваимодействия и переноса маршрутизации на инфинибенд свич. В ИБМовской шине процессорные платы между собой общаются по infiniband , без дополнительных PCI прослоек . Архитектура скрывает infiniband под капотом. То что RAC делает программно , в ИБМе делается аппаратно на уровне IPC. За счет этого получается теоретический профит. Теоретический потому, что программисты верхнего уровня вностят самый большой вклад в тормознутость системы в целом, и обьективно оценить профиты очень тяжело. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2014, 11:48 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Если продолжать сравнение по сабжу , то ИБМ может оказаться в профите за счет аппаратной виртуализации. Когда внутри одной железки собрана и база и сервера приложений. 1. Можно тягать процессоры и память между БД и приложениями на лету. 2. По виртуальному эзернет свичу между виртуалками могут бегать джамба фреймы 64 К. Сетевое оборудование поддерживает только 9К. 3. На сервере можно разметстить прочие приложения например например для офлайновго клиринга с платежными системами и всякие статистические кубы, фрод мониторинг итд. 4. По мере роста количества транзакций и типов нагрузок можно динамически перераспределять ресурсы , что бы система была равномерно нагружена по задачам и в течении периодов, не занимала место в датацентре , не грела в пустую воздух. Весь технологический цикл процессинга на 10 млн карт с фродоммониторингом, клирингом, статистическими кубами и дисковым обьемом помещается 42 юнитовую стойку. Если нужно хранить много истории то в полторы , за счет добавления дисковых полок. + вторая стойка резервирования ( стедбаи , тестовые полигоны функциональнойго и стресс тестирования и прочие песочницы). ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2014, 12:18 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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.12.2014, 12:39 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ChronSQLА какие скоростные интерфейсы встроены непосредственно в кристалл процессора IBM Power7/8? тынц соединяются каждый с каждым или попарно какждая пара с каждой В зависимости от количества процессорных блоков в сервере. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2014, 13:37 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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.12.2014, 13:52 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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.12.2014, 14:02 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
onstat-Что можно еще впихнуть на 6 x Sun Fire, не переделывая систему? ну весь тот современный софт, что на p795 гонять бессмысленно. например биг дата, вместо самопальной аналитики ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2014, 14:15 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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.12.2014, 14:24 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Alexander Ryndinonstat-пропущено... Что можно еще впихнуть на 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.12.2014, 14:29 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Alexander Ryndinonstat-пропущено... Что можно еще впихнуть на 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.12.2014, 14:38 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Yo.!onstat-Что можно еще впихнуть на 6 x Sun Fire, не переделывая систему? ну весь тот современный софт, что на p795 гонять бессмысленно. например биг дата, вместо самопальной аналитики Я не вижу проблем запихнуть в новый LPAR имеющейся 795 машины рядом LPARами SAPа Power Linux & hadoop. Если на уже имеющемся сревере есть гуляющие ресурсы. А 20% есть практически всегда.... Как минуимум стартап можно развернуть и оценить целесобразность развития направления для компании не ввязываять в бюджетный процесс , тендера итд итп.... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2014, 14:55 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
onstat-Я не вижу проблем запихнуть в новый LPAR имеющейся 795 машины рядом LPARами SAPа Power Linux & hadoop. это потому, что вы не увидели, что в документе речь идет о кластере. идеология биг дата - прямая противоположность p795. hadoop с его map-reduce это жутко не неэффективный кластер, который на все и вся фигачит фулскан. вся соль в том, что имея тучу ресурсов, всем пофигу на эту неоптимальность, все радуются конечному результату, пусть и не оптимального, за то очень очень дешево. ставить hadoop на p795 попросту не имеет смысла. по моим расчетам тот p795 стоил $12 млн, т.е. разница с 6х Sun Fire X4800 M2 около $11 млн. с такой разницей на каждую задачу можно хоть новый кластер собирать, а старый в интернат отдавать, детям. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2014, 15:11 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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.12.2014, 15:40 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
PS Причем интересное замечание, что если представить 32 сокета в виде матрицы 4 х 8, то все сокеты в каждой строчке соединены между собой кольцевой шиной, и все сокеты в каждом столбце соединены между собой кольцевой шиной. Кто-нибудь знает, что это за топология и для каких задач она выгодна? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2014, 15:52 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ChronSQLonstat- По вашему тынцу написано: "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.12.2014, 16:24 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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.12.2014, 16:54 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ChronSQLonstat-пропущено... Прошу прощения, я не нашел в открытых источниках информацию, однозначно отвечающую на ваш вопрос. Когда то мимо меня проскакивала презентация что конкретно в этих машинах для Inter-node buses (4 enclosures) 158.02 Gbps infiniband, есть транспортным протоколом для SMP-link ов, для взаимодействия процессорных плат находящихся в разных цеках. А примерно насколько уверены в том, что помните правильно и что автор той презентации не ошибся, 20 / 50 / 90%? Автор может и ошибся , но документация врядли ошибается в числе 158.02 Gbps ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2014, 17:08 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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.12.2014, 17:21 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ChronSQLonstat-пропущено... Автор может и ошибся , но документация врядли ошибается в числе 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 в таблице скорости взаимодействия по кешам , памяти, шинам ввода вывода ........ ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2015, 11:19 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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 показана на картинке. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2015, 20:03 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RAC, Для процессинга не нужен RAC. Достаточно обычного SN кластера. На одном сервере, видимо, сбербанку удобней. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2015, 22:07 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
И взаимодействие между нодами ненужно, если все операции по счету клиента лежат на одной ноде. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2015, 22:09 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
И вообще, ничего ненужно. Но на ИБМе круче, разумеется, да и по цене примерно столько же, сколько без него. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2015, 22:10 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Oracle RACПодскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Складывалась скверная ситуация: с WAY4 могла наступить полная задница, как раз во время прямой трансляции выступления президента В.Путина сегодня днём! Переключиться на Stand-in и откатить патч в дневное время у нас почти невозможно, поскольку резервная база не потянет высокую нагрузку, такое возможно лишь ночью (Stand-in как минимум в 2 раза менее мощный, поскольку он, в отличие от основной базы, почему-то был сделан не в RAC конфигурации по воле архитекторов). Похоже, что основная оракловая база главного процессинга страны таки стоит RAC-ом....и видимо на POWER 795-ых ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2015, 21:22 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
orawayOracle RACПодскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Складывалась скверная ситуация: с WAY4 могла наступить полная задница, как раз во время прямой трансляции выступления президента В.Путина сегодня днём! Переключиться на Stand-in и откатить патч в дневное время у нас почти невозможно, поскольку резервная база не потянет высокую нагрузку, такое возможно лишь ночью (Stand-in как минимум в 2 раза менее мощный, поскольку он, в отличие от основной базы, почему-то был сделан не в RAC конфигурации по воле архитекторов). Похоже, что основная оракловая база главного процессинга страны таки стоит RAC-ом....и видимо на POWER 795-ыха чем бы тут рак помог? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2015, 22:23 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
orawayOracle RACПодскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Складывалась скверная ситуация: с WAY4 могла наступить полная задница, как раз во время прямой трансляции выступления президента В.Путина сегодня днём! Переключиться на Stand-in и откатить патч в дневное время у нас почти невозможно, поскольку резервная база не потянет высокую нагрузку, такое возможно лишь ночью (Stand-in как минимум в 2 раза менее мощный, поскольку он, в отличие от основной базы, почему-то был сделан не в RAC конфигурации по воле архитекторов). Похоже, что основная оракловая база главного процессинга страны таки стоит RAC-ом....и видимо на POWER 795-ых там ниже еще клевый кейс есть. Асинхронный комит, пока нагрузка не спадет. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2015, 22:33 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
SergSuperorawayпропущено... Складывалась скверная ситуация: с WAY4 могла наступить полная задница, как раз во время прямой трансляции выступления президента В.Путина сегодня днём! Переключиться на Stand-in и откатить патч в дневное время у нас почти невозможно, поскольку резервная база не потянет высокую нагрузку, такое возможно лишь ночью (Stand-in как минимум в 2 раза менее мощный, поскольку он, в отличие от основной базы, почему-то был сделан не в RAC конфигурации по воле архитекторов). Похоже, что основная оракловая база главного процессинга страны таки стоит RAC-ом....и видимо на POWER 795-ыха чем бы тут рак помог? А что мешало в дневное время переключится на stand-in и откатить патч снижавший производительность? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2015, 23:27 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Вася УткинSergSuperпропущено... а чем бы тут рак помог? А что мешало в дневное время переключится на stand-in и откатить патч снижавший производительность?а как это возможно? - база то одна и процедуры общие для всех нод (я сталкивался с раком пару раз и только как разработчик, имею весьма общее представление) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2015, 23:43 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
orawayOracle RACПодскажите, почему в банковском карточном процессинге обычно используют один большой сервер, как например, в Сбербанке Way4 база Oracle на сервере IBM p795 (на тысячу ядер) за миллионы долларов, а не несколько серверов в Oracle RAC? Складывалась скверная ситуация: с WAY4 могла наступить полная задница, как раз во время прямой трансляции выступления президента В.Путина сегодня днём! Переключиться на Stand-in и откатить патч в дневное время у нас почти невозможно, поскольку резервная база не потянет высокую нагрузку, такое возможно лишь ночью (Stand-in как минимум в 2 раза менее мощный, поскольку он, в отличие от основной базы, почему-то был сделан не в RAC конфигурации по воле архитекторов). Похоже, что основная оракловая база главного процессинга страны таки стоит RAC-ом....и видимо на POWER 795-ых Как же во время появился глючный патч - рубль падает, с пластиковых карт деньги не снять :) Значит все-таки после "того случая" они как и обещали перенесли базу на RAC. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2015, 23:54 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
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 В реальных (а не бенчмарковых) тяжелых SAP ERP инсталляциях на оракле RAC на "писюках" не используют "чуть меньше чем полностью", а как-то в основном на больших POWER-ах или SPARC-ах без никаких раков. Yo.! учитывая что оракловый софт с SAP идет бесплатно ? Да щас, ага. 15% от SAV или 18% если с RAC-ом. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 10:48 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
orawayСкладывалась скверная ситуация: с WAY4 могла наступить полная задница, как раз во время прямой трансляции выступления президента В.Путина сегодня днём! И ведь ведутся люди на такую утку... Кто-нибудь встречал админа, в личной переписке пишущего "MUTEX" и "президент В.Путин"?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 12:23 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Вася УткинSergSuperпропущено... а чем бы тут рак помог? А что мешало в дневное время переключится на stand-in и откатить патч снижавший производительность? Это базовая теория массового обсуживания..... Технологическая организация любого процессинга, в соотвествии с правилами Платежных Систем. Любая даже минимальная задержка ( таймаут) в отбаботке потока транзакций приводит к лавинообразному росту нагрузки на систему. Остановка потока в 1100 тразакций в секунду на одну минуту , может привести к очереди с тремящеся к 1100 + 60*1100 тразакций. На практике 60*1100 размазывается приблизительно 10-20-30 - минут , что что сотвествует росту ТПСов в 2-3-4-5 раз. Если остановить на 2 минуты , очередь будет стремиться к 120*1100.... А в условиях паники, 60*1100 необслуженных клиентов начинают звонить друзьям и знакомым и создавать дополнительный коэфициент к 60*1100 ..... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 12:41 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ДохтаРВася Уткинпропущено... А что мешало в дневное время переключится на stand-in и откатить патч снижавший производительность? Это базовая теория массового обсуживания..... Технологическая организация любого процессинга, в соотвествии с правилами Платежных Систем. Любая даже минимальная задержка ( таймаут) в отбаботке потока транзакций приводит к лавинообразному росту нагрузки на систему. Остановка потока в 1100 тразакций в секунду на одну минуту , может привести к очереди с тремящеся к 1100 + 60*1100 тразакций. На практике 60*1100 размазывается приблизительно 10-20-30 - минут , что что сотвествует росту ТПСов в 2-3-4-5 раз. Если остановить на 2 минуты , очередь будет стремиться к 120*1100.... А в условиях паники, 60*1100 необслуженных клиентов начинают звонить друзьям и знакомым и создавать дополнительный коэфициент к 60*1100 ..... Т.е. в Сбере нету резервной железки с ораклом без непроверенных патчей и синхронной копией БД на которую можно переключиться за несколько секунд? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 13:01 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Вася УткинТ.е. в Сбере нету резервной железки с ораклом без непроверенных патчей и синхронной копией БД на которую можно переключиться за несколько секунд? Нету, не по карману она им. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 13:39 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Вася УткинДохтаРпропущено... Это базовая теория массового обсуживания..... Технологическая организация любого процессинга, в соотвествии с правилами Платежных Систем. Любая даже минимальная задержка ( таймаут) в отбаботке потока транзакций приводит к лавинообразному росту нагрузки на систему. Остановка потока в 1100 тразакций в секунду на одну минуту , может привести к очереди с тремящеся к 1100 + 60*1100 тразакций. На практике 60*1100 размазывается приблизительно 10-20-30 - минут , что что сотвествует росту ТПСов в 2-3-4-5 раз. Если остановить на 2 минуты , очередь будет стремиться к 120*1100.... А в условиях паники, 60*1100 необслуженных клиентов начинают звонить друзьям и знакомым и создавать дополнительный коэфициент к 60*1100 ..... Т.е. в Сбере нету резервной железки с ораклом без непроверенных патчей и синхронной копией БД на которую можно переключиться за несколько секунд? Я не знаю что у них есть сейчас. Я знаю, вернее знал, когда то , когда участовал на ямере открытом расследовании нашумевшего сбоя, что у них 2-е процессиговые системы WAY4 и SmartVista , База WAY4 занимет польностью 795 машину SmartVista и еще минимум одну 795 машину . Остановка обработки в любой из этих систем для клинета может выглядеть как глобальный сбой процессинга. При такой системе зарезервироваться на все случаи жизни можно только теоритически. А особенно от ситуаций, проявляющихся только под высокой транзакционной нагрузкой. Что самое печальное, что эффективный менеджмент ( не только Российский) не научился считать KPI по предотвращению сбоев, а значит работы предовращению сбоев не оплачивает. Если современный эффективный менеджмент запустит в АЭС то она она врядли протянет больше года до повторения Чернобыля. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 13:56 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ДохтаРЕсли современный эффективный менеджмент запустит в АЭС то она она врядли протянет больше года до повторения Чернобыля. Уже несколько лет в кошмарах снится многим... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 16:29 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
NikolayV81ДохтаРЕсли современный эффективный менеджмент запустит в АЭС то она она врядли протянет больше года до повторения Чернобыля. Уже несколько лет в кошмарах снится многим... Кастате для тех , кто хоть как то занитресован минимизации проблемных ситуаций в своих системах полезно читать расследования любых аварий Например : Как думаете из какого расследования этот текст : Особенность этой аварии, которая очень сильно психологически довлела над всеми нами, в том, что она произошла в штатных условиях . Она произошла, когда всё работало исправно, выполнялись регламенты по ремонту, выполнялись требования по эксплуатации. Никто ничего не нарушил, станция полностью соответствовала всем нормам и требованиям, эксплуатационный персонал выполнял все предписанные регламенты Тынц Жопа наступила , когда все КПИ находились в зеленой зоне ..... (( ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 16:58 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
... что она произошла в штатных условиях . Она произошла, когда всё работало исправно, выполнялись регламенты по ремонту... На сколько я помню из обсуждений в Инет: 1. У "улетевшего" ротора показатели были НЕ в "зеленой зоне". Ремонт выполнялся (и не давно), но вот качество ремонта было достаточно странным (возможно ремонт и помог ротору улететь). 2. Обсуждение оторванных "шпилек", вроде начиналось с того - что они a) еще советские, как поставили, так и стоят b) похоже они вообще были не все c) похоже их заворачивали руками с нарушением правил d) оторвать их должно было уже давно. И на "регламенты по ремонту,.... требования по эксплуатации." все уже давно и надежно положили нано-болт 3. Ремонтную службу "эффективный менеджмент" давно оптимизировал и перевел на аутсоурс. Из Вашей же ссылки к Вики: Википедия....После проведённого ремонта гидроагрегат был принят в постоянную эксплуатацию; при этом были зафиксированы повышенные вибрации оборудования , остававшиеся, тем не менее, в пределах допустимых значений.[1] В ходе эксплуатации гидроагрегата его вибрационное состояние постепенно ухудшалось и в конце июня 2009 года перешло допустимый уровень . Ухудшение продолжилось и в дальнейшем; так, к 8:00 17 августа 2009 года амплитуда вибрации подшипника крышки турбины составляла 600 мкм при максимально допустимых 160 мкм; в 8:13, непосредственно перед аварией она возросла до 840 мкм. В такой ситуации главный инженер станции в соответствии с нормативными документами был обязан остановить гидроагрегат с целью выяснения причин повышенной вибрации, чего сделано не было , что и послужило одной из главных причин развития аварии... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 18:20 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev ... что она произошла в штатных условиях . Она произошла, когда всё работало исправно, выполнялись регламенты по ремонту... На сколько я помню из обсуждений в Инет: 1. У "улетевшего" ротора показатели были НЕ в "зеленой зоне". Ремонт выполнялся (и не давно), но вот качество ремонта было достаточно странным (возможно ремонт и помог ротору улететь). 2. Обсуждение оторванных "шпилек", вроде начиналось с того - что они a) еще советские, как поставили, так и стоят b) похоже они вообще были не все c) похоже их заворачивали руками с нарушением правил d) оторвать их должно было уже давно. И на "регламенты по ремонту,.... требования по эксплуатации." все уже давно и надежно положили нано-болт 3. Ремонтную службу "эффективный менеджмент" давно оптимизировал и перевел на аутсоурс. Из Вашей же ссылки к Вики: Википедия....После проведённого ремонта гидроагрегат был принят в постоянную эксплуатацию; при этом были зафиксированы повышенные вибрации оборудования , остававшиеся, тем не менее, в пределах допустимых значений.[1] В ходе эксплуатации гидроагрегата его вибрационное состояние постепенно ухудшалось и в конце июня 2009 года перешло допустимый уровень . Ухудшение продолжилось и в дальнейшем; так, к 8:00 17 августа 2009 года амплитуда вибрации подшипника крышки турбины составляла 600 мкм при максимально допустимых 160 мкм; в 8:13, непосредственно перед аварией она возросла до 840 мкм. В такой ситуации главный инженер станции в соответствии с нормативными документами был обязан остановить гидроагрегат с целью выяснения причин повышенной вибрации, чего сделано не было , что и послужило одной из главных причин развития аварии... На ваше сообщение я ответил до того как вы написали коментарий :) 17105853 авторЕсли современный эффективный менеджмент запустить в АЭС то она она врядли протянет больше года до повторения Чернобыля. Поэтому интересно читать описание расследований всевозможных проблем с точки зрения всестороннего анализа причин. В большенстве своем причины проблем не технические, а организационные. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 18:51 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ДохтаРВ большенстве своем причины проблем не технические, а организационные. Да ну? А ничего, что к аварии привели конструкционные недостатки турбины в совокупности с конструкционными же недостатками самой станции? Один рукожоп спроектировал турбину, которая идёт штатно вразнос, второй - аварийные системы без автономного аварийного питания, третий - единую точку отказа в виде общего машзала, четвёртый написал софт, регулярно выводящий агрегат на этот самый "нерекомендованный" режим работы. Ну а виноват, конечно, Чубайс, да... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 19:01 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovДохтаРВ большенстве своем причины проблем не технические, а организационные. Да ну? А ничего, что к аварии привели конструкционные недостатки турбины в совокупности с конструкционными же недостатками самой станции? Один рукожоп спроектировал турбину, которая идёт штатно вразнос, второй - аварийные системы без автономного аварийного питания, третий - единую точку отказа в виде общего машзала, четвёртый написал софт, регулярно выводящий агрегат на этот самый "нерекомендованный" режим работы. Ну а виноват, конечно, Чубайс, да... Там не всё так просто, стрелочников искать всегда прощё, такие сооружения по сути "Эксперементальные", и когда они начинают использоваться как ширпотреб, может стать плохо. p.s. любая турбина может пойти в разнос при неправильной эксплуатации ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 19:31 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovДохтаРВ большенстве своем причины проблем не технические, а организационные. Да ну? А ничего, что к аварии привели конструкционные недостатки турбины в совокупности с конструкционными же недостатками самой станции? Один рукожоп спроектировал турбину , которая идёт штатно вразнос, второй - аварийные системы без автономного аварийного питания, третий - единую точку отказа в виде общего машзала, четвёртый написал софт, регулярно выводящий агрегат на этот самый "нерекомендованный" режим работы. Ну а виноват, конечно, Чубайс, да... Насколько я помню то, что когда то читал , Там комплексная проблема. 1 Выбор места ( узкий кнаньон) с цель экономии бетона Энергоблоки тупо не помешаются по ширине , что бы утилизировать всю энергию имеющейся воды. 2. Понты , чутли не самая высокая плотина в мире , и самая высокая эффективность затрат на строительство в расчете на проектную мощьность. 3. Причина не в рукожопе проектировщика турбины, турбина была спроектирована правильно непосредствнно под данное сооружение. Проблема в точности изготовления. По проекту поверхности лопастей и прочие критичные по точности детали должны были делать на заводе , который делал гребные винты подводных лодок на японских станках, но военные послали энергетиков куда подальше , и пришлось делать на том оборудовании, которое нашлось в наличии в соотвествующем министерстве. И под диктовку Министра менять требования к проекту с соотвествующими рисками..... С этого момента могло выстрилить все что угодно , шпильки, подшипники ....... После запуска первой очереди, увидели сумашедшую вибрацию, помимо прочих мероприятий построили аж целую Майнийскую ГЭС , которая должна была регулировать уровень воды за турбиной и тем самым компенсировать допуски точности Саяношушенской ГЭС задавив турбулентность массой воды водохнанилища Майнийской ГЭС. Перед ЦК отчитались еще одной единицей в каскаде Энисейских электостанций , привет KPI И получчили еще по одной медали, за еще одну стройку века :) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 19:34 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ДохтаРНасколько я помню то, что когда то читал С большой долей вероятности, среди нас нет ни одного человека, который бы разбирался в вопросе достаточно, чтобы судить "кто именно рукожоп и насколько". Вопрос лишь в том, кто что читал и кто писал то, что читал конкретный человек. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 19:44 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ДохтаРЕсли современный эффективный менеджмент запустит в АЭС то она она врядли протянет больше года до повторения Чернобыля. простите за серость, а команда Киренко, что уже лет 10 рулит АЭС это кто ? по вашему выпустники физикотехнических ? взгляните на реальность, у этих "дефективных" менеджеров даже бу боинги исправно летают, тогда как у профессионалов СССР простите в редкий, год менее 100 пассажиров гробили. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 19:56 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
softwarerДохтаРНасколько я помню то, что когда то читал С большой долей вероятности, среди нас нет ни одного человека, который бы разбирался в вопросе достаточно, чтобы судить "кто именно рукожоп и насколько" . Вопрос лишь в том, кто что читал и кто писал то, что читал конкретный человек. Полностью согласен. Поэтому я выше сказал о том, что полезно знакомиться с результатами расследования разных аварий. Будь то Чернобыль, ГЭС или авиакатастрофа. Проводить аналогии и делать выводы . ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 19:59 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
softwarerС большой долей вероятности, среди нас нет ни одного человека, который бы разбирался в вопросе достаточно, чтобы судить "кто именно рукожоп и насколько". Вопрос лишь в том, кто что читал и кто писал то, что читал конкретный человек. Саш, ты же достаточно старый, чтобы понимать как возникают "нерекомендованные режимы". Я готов спорить на то, что нахождение точки резонанса точно посередине рабочего режима выявилось уже на динамических испытаниях (поскольку компьютеров чтобы просчитать динамику ещё при проектировании тогда не было), но сроки поджимали и баг документировали как фичу. И это нормально работало бы все 30 расчётных лет, пока к делу не подключилась автоматическая динамическая регулировка мощности. После этого авария уже была фактически запрограммирована. И таки да, предвидеть это всё было практически невозможно, поскольку вряд ли кто-то разработчику софта ЕЭС сказал, что "на ГЭС турбины нестабильные, так что вы там не злоупотребляйте их переключениями-то". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 20:08 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ДохтаРполезно знакомиться с результатами расследования разных аварий. Да, есть такой очень интересный сериал "секунды перед катастрофой", в которой практически все истории сводятся к двум вариантам: "случилось что-то не предвиденное при проектировании" и "предвиденные отклонения сложились и вывели всю систему из равновесия". Ну, не считая тупо человеческих ошибок. Вот и сбербанк наступил на эти грабли, когда условия вышли за рамки средних, а резервов для компенсации отклонения - не было. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 20:34 |
|
Подскажите, почему в банковском карточном процессинге не используют Oracle RAC?
|
|||
---|---|---|---|
#18+
ДохтаР...В большенстве своем причины проблем не технические, а организационные. Полностью согласен. Технические проблемы это детали, а то, что они НЕ устранялись - это уже организационная проблема. Как я помню, даже авария на ЧС из-за концевого эффекта была ВТОРАЯ. Вроде была авария в начале 80-х, благодаря грамотным действиям персонала - развития не получила. Но никаких организационных выводов сделано не было. Пронесло и пронесло. А на ЧС уже не пронесло. Вики...Существование концевого эффекта было обнаружено в 1983 году во время физических пусков 1-го энергоблока Игналинской АЭС и 4-го энергоблока Чернобыльской АЭС ([17], с. 54). Об этом главным конструктором были разосланы письма на АЭС и во все заинтересованные организации. На особую опасность обнаруженного эффекта обратили внимание в организации научного руководителя, и был предложен ряд мер по его устранению и нейтрализации, включая проведение детальных исследований. Но эти предложения не были осуществлены , и нет никаких сведений о том, что какие-либо исследования были проведены, как и (кроме письма ГК) о том, что эксплуатационный персонал АЭС знал о концевом эффекте.... Note: У меня чувство, что читал про аварию на Ленинградской АЭС из-за данного эффекта. Но в Вики об этом не нашел. Могу ошибаться. Саяно-Шушенская тоже не один год работала. Думаю многие ошибки проектирования кому надо были известны. Вопрос, что с ними делали. Исправляли или забивали нано-болт. ДохтаРНа ваше сообщение я ответил до того как вы написали коментарий После чего "все KPI были в зеленой зоне", "когда всё работало исправно, выполнялись регламенты по ремонту, выполнялись требования по эксплуатации". Это НЕ так. p.s. А вообще, ушли в злобный оффтопик. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2015, 20:39 |
|
|
start [/forum/topic.php?all=1&fid=35&tid=1552346]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
199ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
93ms |
get tp. blocked users: |
1ms |
others: | 236ms |
total: | 578ms |
0 / 0 |