Comments 105
А объясните чайнику — банки вроде не вчера появились — неужто у них объём вычислений растёт быстрее Мура? Что за 10 последних лет, что за полвека? Вот 20-30 лет назад как они справлялись?
Объем транзакций растет, растет количество оборудования, регулярно добавляются новые клиентские сервисы. Масштабируемость, кстати, нифига не линейная. Т.е. если банк, у которого количество терминального оборудования (банкоматы, киоски, POS-терминалы) пять лет назад составляло 1000 единиц, в этом году увеличил его до 5000 единиц, то вычмощности ему надо увеличивать не в 5 раз, а, грубо говоря, в 15 раз. И так далее.
Что касается RISC vs x86, ну, тут никаких чудес нет. Просто давно не секрет, что в стоимости больших черных коробок с надписью IBM ***Series и им подобных прячется очень-очень неплохая маржа производителя :) Дело же не в архитектуре, а в покупательной способности участников рынка, на который она ориентирована.
Что касается RISC vs x86, ну, тут никаких чудес нет. Просто давно не секрет, что в стоимости больших черных коробок с надписью IBM ***Series и им подобных прячется очень-очень неплохая маржа производителя :) Дело же не в архитектуре, а в покупательной способности участников рынка, на который она ориентирована.
> выяснили, что x86 подходит и стоит в разы дешевле
шёл 2016 год…
шёл 2016 год…
Я, конечно, далек от этой сферы, но ведь x86 уже двадцать лет как используют под капотом RISC ядро, потому ничего удивительного в возможности замены не вижу :/
т.е. расчеты не в реальном времени, а раз в сутки происходят?
В левом углу ринга — 120 ядер Xeon 2.8Ghz, 2Tb RAM, а в правом какие характеристики?
UFO just landed and posted this here
Возможно речь идёт о насыщении https://www.reddit.com/r/vmware/comments/425j0d/cpu_saturated_workload/
UFO just landed and posted this here
Без гипервизора тоже наблюдал лично в 2009 году.
На сервер СУБД (8 ядер Intel Xeon, 16Гб ОЗУ, Win2003, MS SQL2005) около 40 минут подряд валилась нагрузка, и машина «залипла» почти намертво.
Решилось заменой на Оптероны от AMD (8 ядер, 12 Гб ОЗУ, Win2003, MS SQL 2005).
Потом, ради эксперимента, «залипавшую» машинку грузили на тестовом стенде — она так же точно залипала.
На сервер СУБД (8 ядер Intel Xeon, 16Гб ОЗУ, Win2003, MS SQL2005) около 40 минут подряд валилась нагрузка, и машина «залипла» почти намертво.
Решилось заменой на Оптероны от AMD (8 ядер, 12 Гб ОЗУ, Win2003, MS SQL 2005).
Потом, ради эксперимента, «залипавшую» машинку грузили на тестовом стенде — она так же точно залипала.
Это особенность x86 архитектуры а не CPU.
При большой нагрузке (в unix-like осях, когда load average поднимается до 20-40 и более) производительность x86 начинает резко падать, практически эспоненциально, в то время, как на risk-архитектуре хоть и замедляется, но не сильно.
Скажем load average 60 в linux на x86 — это жестокий фриз, когда между набором даже простейшей команды типа «echo» и ее выполнением проходят десятки секунд, если не минуты, то с точно таким же load average на solaris запущенный на sparc t2000 — система оставалась отзывчивой, пользователи даже не сразу замечали, что что-то вообще не так.
> если бы на домашних тачках такое происходило, наверняка бы трубили об этом.
Ну, те, кто сталкивался — трубят. :)
> Или фильм ты пережимаешь, у тебя estimated 1:00
Пережатие фильма это один поток, он создаст load average = 1. Речь идет о случае, когда количество задач в очереди гораздо больше, чем успевает обрабатывать процессор.
При большой нагрузке (в unix-like осях, когда load average поднимается до 20-40 и более) производительность x86 начинает резко падать, практически эспоненциально, в то время, как на risk-архитектуре хоть и замедляется, но не сильно.
Скажем load average 60 в linux на x86 — это жестокий фриз, когда между набором даже простейшей команды типа «echo» и ее выполнением проходят десятки секунд, если не минуты, то с точно таким же load average на solaris запущенный на sparc t2000 — система оставалась отзывчивой, пользователи даже не сразу замечали, что что-то вообще не так.
> если бы на домашних тачках такое происходило, наверняка бы трубили об этом.
Ну, те, кто сталкивался — трубят. :)
> Или фильм ты пережимаешь, у тебя estimated 1:00
Пережатие фильма это один поток, он создаст load average = 1. Речь идет о случае, когда количество задач в очереди гораздо больше, чем успевает обрабатывать процессор.
Ни разу с таким не сталкивался, в том числе и в гипервизоре запуская математические просчеты на 4 ВМ (по 2 ядра) загружающих полностью сервер с 4 ядрами на сутки-другие, и на ноутбуке запуская рендеринг графики на неделю и умудряясь при этом играть в COD выставив для рендеринга приоритет поменьше, можно конкретные примеры или ссылки на описание проблемы, не понимаю о чем речь.
обычно пережатие фильма эти минимум два потока (аудио, видео) а для HT и того больше благо пережатие прекрасно масштабируется, разве нет? ну и в довесок еще огромное количество потоков ОС, хотя собственно какая разница, сколько потоков если существует планировщик задача которого правильно предоставлять процессорное время всем задачам.
Могу предположить что проблема связана с переключением контекста между задачами и что на эти тяжелые переключения будет тратиться времени больше чем на реальные вычисления, но разве это не лечится правильным кодом, особенно когда сервер занимается вычислением однотипных задач, как например в банковской сфере?
Пережатие фильма это один поток, он создаст load average = 1. Речь идет о случае, когда количество задач в очереди гораздо больше, чем успевает обрабатывать процессор.
обычно пережатие фильма эти минимум два потока (аудио, видео) а для HT и того больше благо пережатие прекрасно масштабируется, разве нет? ну и в довесок еще огромное количество потоков ОС, хотя собственно какая разница, сколько потоков если существует планировщик задача которого правильно предоставлять процессорное время всем задачам.
Могу предположить что проблема связана с переключением контекста между задачами и что на эти тяжелые переключения будет тратиться времени больше чем на реальные вычисления, но разве это не лечится правильным кодом, особенно когда сервер занимается вычислением однотипных задач, как например в банковской сфере?
перечитал комментарии пожалел что оставил этот, жаль не удалить, не хочу ввязываться в этот холивар
> но разве это не лечится правильным кодом, особенно когда сервер занимается вычислением однотипных задач, как например в банковской сфере?
Там идет обслуживание транзакций, в какие-то моменты количество транзакций может быть пиковым, что вызовет значительные задержки, что вызовет создание очереди выполнения всех поступающих после.
Ближайший аналог — работа апача, только апач параллелится, а в банке всем необходимо работать с одной базой.
Там идет обслуживание транзакций, в какие-то моменты количество транзакций может быть пиковым, что вызовет значительные задержки, что вызовет создание очереди выполнения всех поступающих после.
Ближайший аналог — работа апача, только апач параллелится, а в банке всем необходимо работать с одной базой.
Ближайший аналог — работа апача, только апач параллелится, а в банке всем необходимо работать с одной базой.
Тем не менее идет обработка множеством ядер, в чем загвоздка? Почему нельзя приоретизировать некоторые транзакции которые требуют оперативной обработки и например выполнять их, на 8-ми из 64-х ядер?
> Тем не менее идет обработка множеством ядер, в чем загвоздка?
Количество запросов заметно превышает количество потоков? Выстраивается огромная очередь и процессор тратит больше тактов на переключение контекстов, чем на саму работу?
Для сравнения берем примерно 2010-11 год, когда спарки еще не слишком сильно отставали от интела:
— Xeon Nehalem (55xx) — максимально число ядер 4, максимальное число потоков на ядро 2 (тот самый HT), итого 8 потоков на сокет. Максимум сокетов в одной системе — 2(4?).
— IBM Power7 — ядер 8, 4 потока на ядро, итого 32 потока на сокет. Максимум до 32 сокетов в одной системе — IBM Power 795.
— Sparc T3 — ядер 16, 8 потоков на ядро, итого 128 потоков на сокет. Максимум до 4 сокетов в одной системе — SPARC T3-4.
> Почему нельзя приоретизировать некоторые транзакции которые требуют оперативной обработки и например выполнять их, на 8-ми из 64-х ядер?
Для базы данных все все запросы одинаковы, скорее всего у нее просто нет средств приоретизации по каким-то формальным признакам.
Количество запросов заметно превышает количество потоков? Выстраивается огромная очередь и процессор тратит больше тактов на переключение контекстов, чем на саму работу?
Для сравнения берем примерно 2010-11 год, когда спарки еще не слишком сильно отставали от интела:
— Xeon Nehalem (55xx) — максимально число ядер 4, максимальное число потоков на ядро 2 (тот самый HT), итого 8 потоков на сокет. Максимум сокетов в одной системе — 2(4?).
— IBM Power7 — ядер 8, 4 потока на ядро, итого 32 потока на сокет. Максимум до 32 сокетов в одной системе — IBM Power 795.
— Sparc T3 — ядер 16, 8 потоков на ядро, итого 128 потоков на сокет. Максимум до 4 сокетов в одной системе — SPARC T3-4.
> Почему нельзя приоретизировать некоторые транзакции которые требуют оперативной обработки и например выполнять их, на 8-ми из 64-х ядер?
Для базы данных все все запросы одинаковы, скорее всего у нее просто нет средств приоретизации по каким-то формальным признакам.
Количество запросов заметно превышает количество потоков? Выстраивается огромная очередь и процессор тратит больше тактов на переключение контекстов, чем на саму работу?
Т.е. на тот год (2010-2011) все банально упиралось в количество ядер
8*4*32=1024 ядра на Power7
16*8*4=512 ядер на Т3
8*20=160 на HP980+8*E7-8870
получается что в лучшем случае каждому ядру приходилось обсчитывать в 3 раза больше информации чем ядру Т3 и проблема была в том что разнести базу на два сервера нельзя, а больше ядер уже не впихнешь на тот момент? Тогда проблема мне ясна, спасибо за разъяснение:)
Еще вопрос, я ни разу не силен в спарках, правильно понимаю что говоря Sparc T3 с 16 ядрами, 8 потоками на ядро и 4 сокетами подразумевается шкафчик? и в сравнении удельной вычислительной мощи на юнит он получается сравним с тем же DL980 от НР который занимает юнитов 10 от силы?
> Т.е. на тот год (2010-2011) все банально упиралось в количество ядер
Потоков, а не ядер.
Это на x86 привычно, что одно ядро — 2 потока, на других архитектурах их было разное значение, например на спарках — заметно больше.
> Еще вопрос, я ни разу не силен в спарках, правильно понимаю что говоря Sparc T3 с 16 ядрами, 8 потоками на ядро и 4 сокетами подразумевается шкафчик?
Погугли бы? Всего 4U.
Потоков, а не ядер.
Это на x86 привычно, что одно ядро — 2 потока, на других архитектурах их было разное значение, например на спарках — заметно больше.
> Еще вопрос, я ни разу не силен в спарках, правильно понимаю что говоря Sparc T3 с 16 ядрами, 8 потоками на ядро и 4 сокетами подразумевается шкафчик?
Погугли бы? Всего 4U.
Автор упорно нигде не произносит IBM, но почему-то спалился на AIX. Может еще и на названии банка спалится? Плата ведь идет не за RISC-архитектуру — их как грязи сейчас везде, а за отработанные решения известного производителя. Если банку по силам сгородить свой собственный велосипед (или купить чей-то сторонний) из x86, linux и т.п. — флаг в руки.
Да все же просто, пока был старый курс всех устраивали решения от IBM, но времена поменялись и банки, посчитав разницу в цене, уходят в x86, что не удивительно.
Альфа или Сбер. Есть небольшой шанс что это Открытие но навряд ли.
… у них не падает производительность при долгой постоянной нагрузке выше 70–80%
… потому что боевого применения в системах ядра ей нет
… пределы увеличения мощности из-за больших издержек на перетаскивание данных между ядрами
… поскольку и архитектура куда менее «шаманистая»
что это вообще значит?
… потому что боевого применения в системах ядра ей нет
… пределы увеличения мощности из-за больших издержек на перетаскивание данных между ядрами
… поскольку и архитектура куда менее «шаманистая»
что это вообще значит?
В 2011 году скорее всего был HP Superdome на процессорах Itanium, а это другая архитектура и условия. Они закономерно проигрывали IBM + AIX.
Никто и не говорит, что идентичные конфигурации (одинаковое количество памяти и ядер) IBM p-series и HP SDX результаты. Речь идет о соотношении цена/качество, можно добиться сопоставимых и даже лучших результатов за существенно меньшую стоимость.
Никто и не говорит, что идентичные конфигурации (одинаковое количество памяти и ядер) IBM p-series и HP SDX результаты. Речь идет о соотношении цена/качество, можно добиться сопоставимых и даже лучших результатов за существенно меньшую стоимость.
А чего oracle exadata смотреть не стали?
А в правом углу ринга???
Автор,
а залицензировать Oracle 120 ядер x86 сильно дешевле 60-и паверных ядер?
а залицензировать Oracle 120 ядер x86 сильно дешевле 60-и паверных ядер?
Одинаково, у х86 коэфициент 0.5, у Power 1. Собственно в Oracle же не дураки маркетингом занимаются, как только ядро х86 догонит ядро Power у него тоже коэф. станет 1 :)
Стоимость лицензирования одинаковая. Коэффициент на ядро для HP SDX – 0,5, для IBM Power – 1. Учитывая двухкратное количество ядер для HP SDX, получается то на то.
Имел несторожность поучаствовать в банковском проекте в 2011 где в качестве основного сервера базы данных был HP Superdom, HP Unix, Oracle.
Удовольствие неописуемое, когда на закрытии дня (а иногда это надо делать в разгар уже следующего открытого дня) десятки длинных отчетов просто забивали CPU на 100% (это не блокировки БД) и дальше все прочие короткие транзакции от онлайн-пользователей вставали в очередь (таких было около 4000, активных сессий одномоментно около 100). Рядом была инсталляция где на риск-процессорах и солярисе от фуджитсу-сименс работала еще более нагруженная система такой же конфигурации и никаких проблем такого рода не было. Т.е. при наличии длинных транзакций в сессиях, короткие транзакции успешно проходили. Выяснилась закономерность — как только количество транзакций превышало количество ядер, то система начинала страшно тупить. В отличие от риск и соляриса не было квантования времени между сессиями и дальше начинался массовое зависание.и вся эта конструкция умирала по CPU. Закончилось все приобретением сервера от IBM на AIX, а эта конструкция на HP SuperDom стала тестовой средой банка, т.к. нарастить количество ядер в той версии уже было невозможно. Так что оно может быть и экономия, но мой личный опыт показывает, что тогда надо покупать с большим запасом по сравнению с конфигурациями на RISC.
Удовольствие неописуемое, когда на закрытии дня (а иногда это надо делать в разгар уже следующего открытого дня) десятки длинных отчетов просто забивали CPU на 100% (это не блокировки БД) и дальше все прочие короткие транзакции от онлайн-пользователей вставали в очередь (таких было около 4000, активных сессий одномоментно около 100). Рядом была инсталляция где на риск-процессорах и солярисе от фуджитсу-сименс работала еще более нагруженная система такой же конфигурации и никаких проблем такого рода не было. Т.е. при наличии длинных транзакций в сессиях, короткие транзакции успешно проходили. Выяснилась закономерность — как только количество транзакций превышало количество ядер, то система начинала страшно тупить. В отличие от риск и соляриса не было квантования времени между сессиями и дальше начинался массовое зависание.и вся эта конструкция умирала по CPU. Закончилось все приобретением сервера от IBM на AIX, а эта конструкция на HP SuperDom стала тестовой средой банка, т.к. нарастить количество ядер в той версии уже было невозможно. Так что оно может быть и экономия, но мой личный опыт показывает, что тогда надо покупать с большим запасом по сравнению с конфигурациями на RISC.
я далёкий от реалий такого стека человек, поэтому мне непонятно почему весь этот конгломерат технологий сводят к разнице в архитектуре процессоров, как так получается? действительно ли risc/x86 определяет все важные показатели
В отличии от x86 ширпотреба при проектировании новых процессоров sparc часть инструкций ответственных за шифрование и sql реализована прямо в железе процессора, что сильно дороже и не нужно к примеру геймерам. Потому и работает быстрее, плюс почитайте историю самого Оракла — они исторически не на x86 разрабатывались, работали и оптимизировались по производительности.
про тестирование и оптимизацию понятно,
про инструкции непонятно — что, поэтому планирование обработки транзакций не такое удачное?
про инструкции непонятно — что, поэтому планирование обработки транзакций не такое удачное?
Прошу прощения заранее за, может быть, некорректный вопрос. Не подскажите, что за sql инструкции в железе в sparc реализованы?
Недавно статьи на Хабре Оракл выкладывал с презентацией новых процессоров и серверов с этой особенностью, вот первоисточник:
https://www.oracle.com/servers/sparc/resources.html#reports
http://www.oracle.com/us/products/servers-storage/sparc-m7-processor-ds-2687041.pdf
https://www.oracle.com/servers/sparc/resources.html#reports
http://www.oracle.com/us/products/servers-storage/sparc-m7-processor-ds-2687041.pdf
The SPARC M7 processor incorporates 32on-chip Data Analytics Accelerator(DAX) engines that are specifically designed to speed up analytic queries.
The accelerators offload query processing and perform real-time data decompression, capabilities that are also referred to as SQL in Silicon.
With such query acceleration, Oracle Database 12c delivers performance that is up to 10 times faster compared to other processors.
вот ещё
What Is the SPARC M7 Data Analytics Accelerator?
https://community.oracle.com/docs/DOC-994842
What Is the SPARC M7 Data Analytics Accelerator?
https://community.oracle.com/docs/DOC-994842
В 2011-м не существовало Superdome X, о котором в статье. HP-UX на архитектуру x86 не портирован и вряд ли будет.
UFO just landed and posted this here
Цена контекст свича, в которую входят как минимум следующие факторы: interrupt latency, аппаратная поддержка HT/SMP/NUMA, особенности MMU, доступность управления кэш памятью и ее архитектура, цена обработки исключений, реализации атомарных операций на разных архитектурах существенно отличаются.
OS конечно тоже накладывает дополнительные ограничения например может не использовать большие страницы изза чего больше поток мета информации для поддержки многозадачности и как следстви более долгое переключение между задачами или в случае худшей чем O(1) возможности масштабирования подсистем упираться в это на определенных задачах, неправильно управлять ресурсами, что ведет к низкой эффективности использования их ПО.
OS конечно тоже накладывает дополнительные ограничения например может не использовать большие страницы изза чего больше поток мета информации для поддержки многозадачности и как следстви более долгое переключение между задачами или в случае худшей чем O(1) возможности масштабирования подсистем упираться в это на определенных задачах, неправильно управлять ресурсами, что ведет к низкой эффективности использования их ПО.
По тексту статьи выходит, что как бы х86 они за рубли покупают, в отличие от долларовых АРМов?
Подождите-ка. Как это железо может быть крупносерийным, если фабрики и чипсеты XNC2 — это местное решение на своих ASIC?
UFO just landed and posted this here
Простите за вопрос, а вы хорошо знаете предмет?
После слов про мощность x86 > RISC, а также после сравнение ARM и RISC от IBM я сильно в этом засомневался.
После слов про мощность x86 > RISC, а также после сравнение ARM и RISC от IBM я сильно в этом засомневался.
UFO just landed and posted this here
Производительность в чём измеряете?
и да, опять утверждаю, что x86 намного более производителен (я не о тактах, а о производительности), чем любой ARM\MIPS
Тут я даже спорить не стану, все верно. Только в статье IBM Power, а вы про ARM. Это более чем не одно и то же.
Как вы измеряете производительность на каких задачах?
На каких алгоритмах?
Сколько по вашему у X86 регистров?
А у RISC/MISC (ARM/PPC/MIPS/Z/68K/SPARC/ALPHA/PARISC) и на что это влияет?
С какими архитектурами из этих вы знакомы как эксперт? Чем SMP отличается от NUMA? Как на них устроены/реализованы ALU? Cache? MMU? Data reader Data Writer? Атомарные операции? Какие доступны возможности управления этим (cache, mmu, data reader/writer)? Какие операции могут быть условны? И как это влияет на производительность?
Сколько тактов выполняются операции LD/ST, сравнения, условных переходов? Какие возможности SIMD? Какие на них C/C++ ABI? Как ABI влияет на производительность?
На каких алгоритмах?
Сколько по вашему у X86 регистров?
А у RISC/MISC (ARM/PPC/MIPS/Z/68K/SPARC/ALPHA/PARISC) и на что это влияет?
С какими архитектурами из этих вы знакомы как эксперт? Чем SMP отличается от NUMA? Как на них устроены/реализованы ALU? Cache? MMU? Data reader Data Writer? Атомарные операции? Какие доступны возможности управления этим (cache, mmu, data reader/writer)? Какие операции могут быть условны? И как это влияет на производительность?
Сколько тактов выполняются операции LD/ST, сравнения, условных переходов? Какие возможности SIMD? Какие на них C/C++ ABI? Как ABI влияет на производительность?
Предлагаю загуглить какие еще, кроме ARM, существуют RISC-процессоры, и какие из них ставит в свои машины IBM. Сразу уменьшится пафосность первого предложения и п.3
Давайте составим ряд: 1GHz Xeon, 1GHz Opteron, 1GHz Xeon Phi, 1GHz Maxwell (RISC). Как будем ранжировать? 1GHz — это частота чего?
позиция оракла, официальная, которую они нам рекомендовали:
sparc (серверы Sun) + solaris + Database 12c или на худой legacy случай 11g
или
x86 (серверы Exalogic) + OEL (UEK + RedHat) + Database 12c или на худой legacy случай 11g
всё остальное Оракл прямым текстом не рекомендует и фактически отказывается сопровождать при проблемах с производительностью.
AIX при проблемах производительности они кстати тоже нехотя поддерживают, не рекомендуют, и ни какой сверх производительности не гарантируют.
несколько вопросов к авторам:
Почему был выбран огород из официально не рекомендованных версий дистрибутивов ОС и железа на которых не гарантируется максимальная производительность?
Почему не был применён официально рекомендованный Ораклом InfiniBand?
Зачем был выбран медленный Fiber Channel в свете предыдущего вопроса?
В вашей инсталляции Database на голом железе без виртуализации?
Что в вашей схеме делают 1 Гигабитные сетевые подключения? Почему не 10G?
sparc (серверы Sun) + solaris + Database 12c или на худой legacy случай 11g
или
x86 (серверы Exalogic) + OEL (UEK + RedHat) + Database 12c или на худой legacy случай 11g
всё остальное Оракл прямым текстом не рекомендует и фактически отказывается сопровождать при проблемах с производительностью.
AIX при проблемах производительности они кстати тоже нехотя поддерживают, не рекомендуют, и ни какой сверх производительности не гарантируют.
несколько вопросов к авторам:
Почему был выбран огород из официально не рекомендованных версий дистрибутивов ОС и железа на которых не гарантируется максимальная производительность?
Почему не был применён официально рекомендованный Ораклом InfiniBand?
Зачем был выбран медленный Fiber Channel в свете предыдущего вопроса?
В вашей инсталляции Database на голом железе без виртуализации?
Что в вашей схеме делают 1 Гигабитные сетевые подключения? Почему не 10G?
Гигабиты там встроенны, а фразу «10GbE: 4 x 10G SFP+» вы не заметили?
Если внимательно изучить схему, то видно что платформа возможно этими 10 гигабитными портами и подключается к основному коммутатору, но дальше идёт чистый гигабит по схеме, вот этот момент и настораживает, особенно в резрезе связи с аналитическим сервером, это бутылочное горлышко для любой аналитики, которая при своей работе существенно нагружает канал к серверу БД, особенно если отчёты смотрят тысячи пользователей. Даже если запросы однотипные, лежат в кеше и оттуда же сервером БД и отдаются.
А Оракел после покупки Сана хоть что-то кроме своих железок рекомендует?
Еще бы, как же иначе, ведь они продают это железо. Странно, если бы они его не предлагали всем подряд.
С каких пор FC стал медленным? Много вы знаете внедрений IB в качестве транспорта систем хранения данных?
С каких пор FC стал медленным? Много вы знаете внедрений IB в качестве транспорта систем хранения данных?
Ну как сказать, давайте сравним 4 гигабита на канал и 40 гигабит на канал…
Рекомендую (но не рекламирую !) вам изучить архитектуру полношкафного решения exalogic в котором IB основной транспорт между диском, серверами БД и приложений.
Рекомендую (но не рекламирую !) вам изучить архитектуру полношкафного решения exalogic в котором IB основной транспорт между диском, серверами БД и приложений.
Массмаркет не поддерживает IB для хранилок в большинстве своем.
в статье нашел упоминание про 16Gb FC. 16Gb можно более чем сравнивать с 40Гбит.
А еще я вам один секрет скажу, сейчас никто (почти) не покупает даже 16Gb FC (хотя уже вышел 32Gb), потому что пропускная способность канала значит не так много, когда транспорт построен грамотно. Так как для всех подключений стораджа к серверам используется multipathing, то это минимум 2, а обычно 4 линка, то есть 32Gb.
Я знаю ооочень маленькое количество массивов, которые способны выдать такой поток данных и не умереть. Это High-end массивы, которые обычно подключаются гораздо бОльшим числом линков.
Так что все эти 40Gb — далеко не показатель.
А еще я вам один секрет скажу, сейчас никто (почти) не покупает даже 16Gb FC (хотя уже вышел 32Gb), потому что пропускная способность канала значит не так много, когда транспорт построен грамотно. Так как для всех подключений стораджа к серверам используется multipathing, то это минимум 2, а обычно 4 линка, то есть 32Gb.
Я знаю ооочень маленькое количество массивов, которые способны выдать такой поток данных и не умереть. Это High-end массивы, которые обычно подключаются гораздо бОльшим числом линков.
Так что все эти 40Gb — далеко не показатель.
… только реальная, а не маркетинговая, характеристика, которая отделяет top mid-range от Hi-End массивов — это возможность подключения по FICON.
я поклонник мнения, что Hi-end массивы отделяются от midrange надежностью, внутренней архитектурой. Но в сообщении выше top of mid-range я тоже отнес к категории Hi-end.
Ficon почти мертв и скоро совсем не останется таких массивов=)
Ficon почти мертв и скоро совсем не останется таких массивов=)
«FICON почти мертв»… а еще «FС почти мертв», и «HDD почти мертв»… вспоминая из своей молодости — «панк не мертв, он всегда так пахнет».
со всем уважением к вашему мнению, hi-end СХД — это то, что может работать с мейнфреймами, в таком случае кроме всех признаков (архитектура кэшей, матричная коммутация контроллеров, и пр.) явно выделяется ровно один признак — либо файкон есть, либо его нет.
например, Huawei OceanStor 18000 V3 — есть и матричная коммутация контроллеров, и инфинибэнд, и впечатляющие IOPs, и прочая прочая — но он не Hi-End.
тогда как, например — HDS G1000, он же HPE XP7 — IOPs заявлено в 4 раза меньше, чем у хуавей, но — есть FICON — и это уже Hi-End.
тот же HDS G800 — топ мидренжа
со всем уважением к вашему мнению, hi-end СХД — это то, что может работать с мейнфреймами, в таком случае кроме всех признаков (архитектура кэшей, матричная коммутация контроллеров, и пр.) явно выделяется ровно один признак — либо файкон есть, либо его нет.
например, Huawei OceanStor 18000 V3 — есть и матричная коммутация контроллеров, и инфинибэнд, и впечатляющие IOPs, и прочая прочая — но он не Hi-End.
тогда как, например — HDS G1000, он же HPE XP7 — IOPs заявлено в 4 раза меньше, чем у хуавей, но — есть FICON — и это уже Hi-End.
тот же HDS G800 — топ мидренжа
Это давний холивар, мнения по этому вопросу у каждого свое. Ваше мнение довольно распространенное, хотя его поклонников становится все меньше.
Я просто не вижу смысла выделять целый класс устройств по одному, такому незначительному признаку. Завтра какой-нибудь Huawei возьмет и добавит к своей младшей линейке поддержку FICON (ну еще пару лет потратит на сертификацию), не будем же мы S2600T называть Hi-end?
в последнее время, если смотреть на вендоров, то Hi-end оборудование часто выделяется только за счет своей цены=) Например, NetApp FAS8080 ничем архитектурно не отличается от 8020, а они называют его Hi-end.
Это уже вопрос больше религии, чем реальное разделение.
Все вышенаписанное — не более чем мои размышления. Точку зрения не навязываю, это просто мое воззрение на сегодняшний рынок СХД.
Я просто не вижу смысла выделять целый класс устройств по одному, такому незначительному признаку. Завтра какой-нибудь Huawei возьмет и добавит к своей младшей линейке поддержку FICON (ну еще пару лет потратит на сертификацию), не будем же мы S2600T называть Hi-end?
в последнее время, если смотреть на вендоров, то Hi-end оборудование часто выделяется только за счет своей цены=) Например, NetApp FAS8080 ничем архитектурно не отличается от 8020, а они называют его Hi-end.
Это уже вопрос больше религии, чем реальное разделение.
Все вышенаписанное — не более чем мои размышления. Точку зрения не навязываю, это просто мое воззрение на сегодняшний рынок СХД.
Позиция Oracle легко объяснима, Oracle — производитель программных продуктов в первую очередь рекомендует Oracle — производителя оборудования (серверов и СХД).
Что касается поддержки. То, что выпишите, не совсем верно — продукты Oracle официально работают и поддерживаются на множестве платформ (Linuх, AIX и т.д.), и при правильном выборе конфигурации никаких проблем с производительностью у вас не будет, а Oracle будет осуществлять полную техническую поддержку. Все остальное — это стратегия продаж: наше ПО лучше всего работает и поддерживается на нашем оборудовании.
Отказ разбираться с проблемами производительности — это достаточно стандартный случай, если вы используете мультивендорное решение. Производитель ПО будет пенять в сторону производителя железа, и наоборот.
Почему был выбран огород из официально не рекомендованных версий дистрибутивов ОС и железа на которых не гарантируется максимальная производительность?
С чего вы взяли? Полностью сертифицированная и согласованная с HP конфигурация. SDX + ОС RHEL
Выдержка из документации HP:
HPE BL920s Gen8 Server Blades
• Red Hat Enterprise Linux (RHEL)
• SUSE Linux Enterprise Server (SLES)
• Microsoft Windows Server 2012 R2 Standard and Datacenter (including Microsoft
SQL Server 2014)
• VMware vSphere 5.5 U2 and 6.0
NOTE: Please be advised there are currently no WBEM providers for VMware
running on Superdome X meaning IRS cannot report OS message traffic.
Почему не был применён официально рекомендованный Ораклом InfiniBand?
Применен где? Для подключения к SAN? В инфраструктуре заказчика не используется InfiniBand.
Зачем покупать и устанавливать специальные коммутаторы InfiniBand, подключать их к имеющемуся SAN.
Кроме того Oracle рекомендует использовать InfiniBand для определённого класса решений – облачной инфраструктуры.
Зачем был выбран медленный Fiber Channel в свете предыдущего вопроса?
Есть существующая инфраструктура, она реализована на FC. Достаточность скорости FC в реальных задачах — вопрос дискуссионный. Очень редко можно увидеть на 100% загруженный SAN.
В вашей инсталляции Database на голом железе без виртуализации?
Да
Что в вашей схеме делают 1 Гигабитные сетевые подключения? Почему не 10G?
Потому что у заказчика есть реальная сетевая инфраструктура, в которой пока активно не используется 10G. Была задача сравнить две платформы в существующем окружении.
Что касается поддержки. То, что выпишите, не совсем верно — продукты Oracle официально работают и поддерживаются на множестве платформ (Linuх, AIX и т.д.), и при правильном выборе конфигурации никаких проблем с производительностью у вас не будет, а Oracle будет осуществлять полную техническую поддержку. Все остальное — это стратегия продаж: наше ПО лучше всего работает и поддерживается на нашем оборудовании.
Отказ разбираться с проблемами производительности — это достаточно стандартный случай, если вы используете мультивендорное решение. Производитель ПО будет пенять в сторону производителя железа, и наоборот.
Почему был выбран огород из официально не рекомендованных версий дистрибутивов ОС и железа на которых не гарантируется максимальная производительность?
С чего вы взяли? Полностью сертифицированная и согласованная с HP конфигурация. SDX + ОС RHEL
Выдержка из документации HP:
HPE BL920s Gen8 Server Blades
• Red Hat Enterprise Linux (RHEL)
• SUSE Linux Enterprise Server (SLES)
• Microsoft Windows Server 2012 R2 Standard and Datacenter (including Microsoft
SQL Server 2014)
• VMware vSphere 5.5 U2 and 6.0
NOTE: Please be advised there are currently no WBEM providers for VMware
running on Superdome X meaning IRS cannot report OS message traffic.
Почему не был применён официально рекомендованный Ораклом InfiniBand?
Применен где? Для подключения к SAN? В инфраструктуре заказчика не используется InfiniBand.
Зачем покупать и устанавливать специальные коммутаторы InfiniBand, подключать их к имеющемуся SAN.
Кроме того Oracle рекомендует использовать InfiniBand для определённого класса решений – облачной инфраструктуры.
Зачем был выбран медленный Fiber Channel в свете предыдущего вопроса?
Есть существующая инфраструктура, она реализована на FC. Достаточность скорости FC в реальных задачах — вопрос дискуссионный. Очень редко можно увидеть на 100% загруженный SAN.
В вашей инсталляции Database на голом железе без виртуализации?
Да
Что в вашей схеме делают 1 Гигабитные сетевые подключения? Почему не 10G?
Потому что у заказчика есть реальная сетевая инфраструктура, в которой пока активно не используется 10G. Была задача сравнить две платформы в существующем окружении.
Эмэсэйка под супердомом, конечно, порадовала :D
Из моего опыта архитектура процессора, можно сказать, вообще не влияет на общую производительность. Гораздо важнее параметрвы конфигурации дискового хранилища и роутеров для связи с этим хранилищем.
Так что статья не раскрывает полную картину.
Так что статья не раскрывает полную картину.
Я думаю, окончательные выводы можно будет делать по результатам реальной эксплуатации. x86 номинально обеспечивает гораздо лучшую производительность/стоимость, но в реальности, так как и сам Linux, и Linux в комплексе с железкой, на которой он стоит – это сборная солянка, то гораздо выше шансы напороться на хитрую несовместимость компонентов внутри системы. А потом начинается перекидывание ответственности. Но можно ли за 450 лямов решить эти проблемы? Наверное, можно.
И совсем другое дело, что известная корпорация, подразумеваемая в статье, сейчас делает всё, чтобы подорвать доверие к себе разработчиков, ликвидируя или распродавая один ключевой технологический компонент за другим.
И совсем другое дело, что известная корпорация, подразумеваемая в статье, сейчас делает всё, чтобы подорвать доверие к себе разработчиков, ликвидируя или распродавая один ключевой технологический компонент за другим.
Я немного далек от банковской сферы, но зачем закупать такие зверские железки, а не накупить кучи обычных серваков, там по 2-4 процессора и считать в каком-нить hadoop-е, если не нужно прям сейчас это посчитать. При том как я понимаю тут нужно в основом считать, а это как раз параллелится отлично, и разница очень небольшая между процессорами последних лет 5ти. Мне не до конца ясна проблема банковкого процессина из статьи, поэтому и спрашиваю. Кажется, что не нужно такой сильно связанности между процессорами.
Это связано с природой данных и профилем нагрузки, а также с устоявшимися методами их обработки. Hadoop предназначен для решения совсем других задач, нежели отказоустойчивая онлайн репликация боевых баз в базу для хранилища, расчёта агрегатов, и онлайн аналитика для BI. Не стоит путать технологии и архитектуру для распределённых вычислений и работы с большими объёмами не структурированных данных с архитектурой для обработки больших объёмов структурированных транзакционных и партицированных массивов данных.
А почему использовали E7-2890 v2 и DDR3 вместо E7-8890 v3 и DDR4?
Сомнительная экономия: Жертва 20% производительности ради 2% денег?
Или я что-то не внимательно прочитал?
И ещё один вопрос:
Чем предложенная конфигурация лучше, чем обычные решения 4 * E7 с самым стандатным соединением по Infiniband EDR?
Это гораздо дешевле, чем предложенное в данной статье. Массштабируется в разы крупнее при практически той же пропускной способности. А уменьшение гемороя в настройке/поддержке/апгрейдах, рискну предложить, на порядок меньше будет.
Сомнительная экономия: Жертва 20% производительности ради 2% денег?
Или я что-то не внимательно прочитал?
И ещё один вопрос:
Чем предложенная конфигурация лучше, чем обычные решения 4 * E7 с самым стандатным соединением по Infiniband EDR?
Это гораздо дешевле, чем предложенное в данной статье. Массштабируется в разы крупнее при практически той же пропускной способности. А уменьшение гемороя в настройке/поддержке/апгрейдах, рискну предложить, на порядок меньше будет.
А почему использовали E7-2890 v2 и DDR3 вместо E7-8890 v3 и DDR4?
Сомнительная экономия: Жертва 20% производительности ради 2% денег?
В данном случае нельзя судить о такой экономии. Такова конфигурация демо-оборудования, которое можно было заказать осенью 2015г.
По результатам тестирования заказчик, естественно, может заказать E7 v3 и DDR4.
Чем предложенная конфигурация лучше, чем обычные решения 4 * E7 с самым стандатным соединением по Infiniband EDR?
Абсолютно другие задачи. Решения Infiniband EDR предназначены для организации облачной инфраструктуры, повышения его сетевой производительности.
Можно соединить по Infiniband 4 сервера на процессорах E7, установить на каждый ОС и распределить между ними задачи или запустить несколько приложений, но нельзя собрать один большой 120 ядерный сервер для работы с большой БД. По настройке/поддержке сложно сказать что-то, т.к. пока нет опыта по эксплуатации Infiniband EDR от Oracle, система не так давно анонсирована.
Сомнительная экономия: Жертва 20% производительности ради 2% денег?
В данном случае нельзя судить о такой экономии. Такова конфигурация демо-оборудования, которое можно было заказать осенью 2015г.
По результатам тестирования заказчик, естественно, может заказать E7 v3 и DDR4.
Чем предложенная конфигурация лучше, чем обычные решения 4 * E7 с самым стандатным соединением по Infiniband EDR?
Абсолютно другие задачи. Решения Infiniband EDR предназначены для организации облачной инфраструктуры, повышения его сетевой производительности.
Можно соединить по Infiniband 4 сервера на процессорах E7, установить на каждый ОС и распределить между ними задачи или запустить несколько приложений, но нельзя собрать один большой 120 ядерный сервер для работы с большой БД. По настройке/поддержке сложно сказать что-то, т.к. пока нет опыта по эксплуатации Infiniband EDR от Oracle, система не так давно анонсирована.
А что тестировали в такой сборке, имея на бэк-енде MSA2040?)
Если вопрос ко мне, то у нас back-end на дешёвой супермикре по infiniband, а не HP по FC ни разу.) VMware + Oracle трудятся под наши задачи великолепно. Чего там тестировать? Тысячи раз протестированный ширпотреб. Запустил и работает...)
MSA — только для загрузки ОС.
MSA2040 используется для операционной системы. Данные для тестирования находились на Hi-end массиве, подключенному по FC.
Во всём этом меня страшно смущает, что вы «non-x86» используете для описания дорогущих мейнфреймов.
А IRL есть ещё сервера на армах, и чем дальше, тем их больше. И они тоже x86, но совсем не мейнфреймы.
А IRL есть ещё сервера на армах, и чем дальше, тем их больше. И они тоже x86, но совсем не мейнфреймы.
«Кроме того, RISC-машины лишены традиционного недостатка x86 при высокой нагрузке — у них не падает производительность при долгой постоянной нагрузке выше 70–80%» — поясните этот бред, пожалуйста?
Это выглядит странно в контексте того, что подавляющее большинство суперкомпьютеров работает на х86 в виде Xeon'ов, Xeon'ов Phi и (изредка) Opteron'ов.
Это не выглядит странно, сильно разные сценарии.
В чём различия?
Откройте мою статью шестилетней давности https://habrahabr.ru/post/90677/ и ответте на вопрос, почему апач перестал отвечать на запросы, когда loadavg выросла больше 50.
Погода на Марсе — такая же причина, как и архитектура процессора 17-летней давности. Никакой аргументации в пользу вашей гипотезы я не увидел в статье.
По поводу высокой постоянной нагрузки — в бытность свою тестировщиком системы биллинга сотовой связи (работала на HP PA-RISC), мы логи выводили в job для spool'ера принтера — чтоб не «вешать» старое железо. У этого самого spooler'а был низкий приоритет процесса.
Про различия в типе нагрузки вы так же не ответили на вопрос.
По поводу высокой постоянной нагрузки — в бытность свою тестировщиком системы биллинга сотовой связи (работала на HP PA-RISC), мы логи выводили в job для spool'ера принтера — чтоб не «вешать» старое железо. У этого самого spooler'а был низкий приоритет процесса.
Про различия в типе нагрузки вы так же не ответили на вопрос.
Я не даю готовых ответов, я предлагаю вам изучить вопрос самостоятельно.
Претензия к вам была в недостаточной, на мой взгляд, обоснованности утверждения о том, что х86 «тупит» при постоянных высоких нагрузках. Не более, не менее.
Ну, я привожу факты, то, что может проверить любой человек на собственном пц — создать заметно бОльшее количество запросов, чем успевает обрабатывать система и посмотреть к какому эффекту это приводит.
Если интересно, то надо дальше самими искать. Всяческие сравнения делались и пятнадцать, и пять лет назад, графики поведения высоконагруженных систем публиковались, хотя сейчас найти с ходу неудалось.
Впринципе, достаточно посмотреть по годам топ бенчмарка olap-систем. Еще даже лет семь назад там никаким x86 не пахло, даже в виде очень многопроцессорных систем.
Если интересно, то надо дальше самими искать. Всяческие сравнения делались и пятнадцать, и пять лет назад, графики поведения высоконагруженных систем публиковались, хотя сейчас найти с ходу неудалось.
Впринципе, достаточно посмотреть по годам топ бенчмарка olap-систем. Еще даже лет семь назад там никаким x86 не пахло, даже в виде очень многопроцессорных систем.
А вы с Хуавэй KunLun 9016/9032, случайно, не сталкивались?
Как там построено связь между процессорами?
Под те же задачи, что и BL920e, он подходит?
Как там построено связь между процессорами?
Под те же задачи, что и BL920e, он подходит?
Sign up to leave a comment.
Тихая революция: внедрение x86-архитектуры вместо RISC-машин для процессинга банка