Computing power comparison: mainframe versus Intel Xeon

[flip_flop]

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

Хе-хе, раз обещал - надо отвечать. Прочитал, пытался быть внимательным, но сильно времени тратить жалко. Отчёт явно буллшитит, хоть и не то чтобы явно врёт ("никогда не ври, если можно буллшитить").

Отмеченный буллшит:
1) сравнивается МФ как с подобной архитектурой (одиночная машина, scale up), так и с другой (кластер из двух машин, scale out: application server + DB server). Фигуральное масштабирование до 2 ядер относится только для application server, тогда как DB server работает в полной конфигурации. Масштабирование до 2 ядер - буллшит. Но этого и не требовалось, это перебор и издержки.
2) на стр. 13 зачем то умножается пропускная способность на процент утилизации CPU для "delivered MIPS". Не уверен, что они это делают для своих машин, и тем более не понятно, зачем это нужно.

Я что-то ещё упустил?

Тем не менее, простое сравнение одной машинки (server application) с МФ было бы достаточно - сравнение не в пользу МФ (в особенности график 7). Ну да, 8 ГБ мало, но указано что это как бы типовая конфигурация. Не знаю, на МФ не работаю, ничего не могу сказать.

Не надо забывать, что авторы отчётов и статейй - сильно заинтересованные стороны, трудно от них ожидать обьективности, хе-хе. "Vendors speaks"

Как делают нормальные тесты? Например, SPEC CPU (spec. org), или TPC-C, или TOP500/Green500/etc/. Публикуют собственно тесты и приглашают всех принять участие. Фирмы сами, со всеми лучшими спецами, оптимизируют конфигурации, компиляторы, выжимают максимум производительности и публикует результаты. Поэтому и хотелось бы нечто подобного от нашпигованного по максимуму z14 и от нашпигованных по максимуму x86 серверных машинок от HP, Oracle и т.д. Причём мне были бы интересны не кластерные решения (тут как бы "и так всем понятно" [zVlad] ), а SMP, scale up, их тоже есть на х86. "Хотелось бы, но не могу"

По поводу процессоров и их скорости - не стоит принижать ни современные процессоры для z14 МФ ("бегут очень медленно") ни современные х86 процессоры ("застой где-то с 201х года"). Ни то, ни другое не отражает действительности. Я могу очень детально привести аргументы с точки зрения микроэлектроники и немного с точки зрения низкоуровневой архитектуры, но боюсь никому не будет интересны такие детали.

[iDesperado]

SK Telecom совсем не мелкий оператор, 30 млн сабскрайберов. Не на много меньше отдельно взятых из амерканской тройки.
Проблемы именно посчитать текущие CDR, даже в реалтайме, нет давно, считали же как-то 20 лет назад, без хадупов и тыщ ядер.

ну пусть не мелкий, но это другая задача (DWH), на этой задаче хадупы с тыщ ядер уже с успехом подвинули все остальное.

Вы серьёзно думаете, что данные для важной системы положат в софт с таким качеством да еще и без поддержки?

кладут. мало что ли хадупов в банках и телекомах ? канторы попроще и без поддержки кладут.

Целый сбербанк уже несколько лет целенаправлено пытается это всё запилить, но пока еще как-то нет результата. Конторы поменьше не смогут себе позволить иметь столько квалифицированных спецов.

да, конторы поменьше не могут позволить себе исследования и нащупывания подходов как сбер с apache ignite, но когда сбер этот этап пройдет остальным переход станет много дешевле. и повторится у инмемори гридов история аля хадуп, а оракл с идеей "запросы отправляют на стойки памяти" запросто может проиграть. пора ораклу снижать цены.

[zVlad]

......
Отмеченный буллшит:
1) сравнивается МФ как с подобной архитектурой (одиночная машина, scale up), так и с другой (кластер из двух машин, scale out: application server + DB server). Фигуральное масштабирование до 2 ядер относится только для application server, тогда как DB server работает в полной конфигурации. Масштабирование до 2 ядер - буллшит. Но этого и не требовалось, это перебор и издержки.
2) на стр. 13 зачем то умножается пропускная способность на процент утилизации CPU для "delivered MIPS". Не уверен, что они это делают для своих машин, и тем более не понятно, зачем это нужно.

Я что-то ещё упустил?
....

По-моему достаточно чтобы дальше не продолжать и забыть об этом "труде" "компьютерных наук".
Я могу лишь добавить что, не знаю как на х86, но на мф практически любой результат можно улучшить не потратив ни цента, тем более что на первых страницах они честно говорят что никакими оптимизациями на мф не занимались, мол так и заведено. Очередной булшит, кстати.
Такой жe булшит как и про 8 GB RAM. В моделях начала 90х достигалось 9 GB, а в используемых в тесте z10 (2008 года) - 1.5 TB. А в тесте берут 8 GB для теста с базой данных где размер RAM напрямую связан с производительностью даже если всю базу в память на запихать.
Разница в 128 раз по RAM и в 40 раз по cores тебя, похоже, до сих пор не напрягает? А там что под лозунгом "так принято" ввод-вывод зажали до 2 Gb/sec против 8 Gb/sec. И потом на голубом глазу делают вычисления MIPS, которые вообщем то для относительных пропорций между разными мф используется, а не чтобы соотноситься с другими платформами, на которых такого же показателя нет, верно?

[flip_flop]

По-моему достаточно чтобы дальше не продолжать и забыть об этом "труде" "компьютерных наук".

Ok, больше можно не продолжать, но мы продолжаем

Разница в 128 раз по RAM и в 40 раз по cores тебя, похоже, до сих пор не напрягает?

Ну так нам так много твердили что и RAM и cores разные, "золотые" на МФ и "так себе" на х86, приходится брать количеством Ну, а если серьёзно, то надо скорее мерятся сокетами а не ядрами: как распорядится ядрами, кешами, IO внутри процессора - зависит от задачи, архитектуры и истории разработок. А ещё лучше, как я и говорил - меряние конечными машинами, оптимизированными производителями, без буллшита.

Ладно, давай таки больше об этом опусе не продолжать, каких только чудернастых белых статей я не видел

[zVlad]

......
Ok, больше можно не продолжать, но мы продолжаем
.......
Ну так нам так много твердили что и RAM и cores разные, "золотые" на МФ и "так себе" на х86, приходится брать количеством Ну, а если серьёзно, то надо скорее мерятся сокетами а не ядрами: как распорядится ядрами, кешами, IO внутри процессора - зависит от задачи, архитектуры и истории разработок. А ещё лучше, как я и говорил - меряние конечными машинами, оптимизированными производителями, без буллшита.

Ладно, давай таки больше об этом опусе не продолжать, каких только чудернастых белых статей я не видел

Нет уж, раз мы переступили через некорректную интерпретацию недобросовестно полученных результатов и ты перевернул эту страницу, начав новую тему, то я не могу не присоединиться к твоему призыву.
RAM и cores конечно разные, но когда вопрос ставится о производительности, тем более производительности на задачах с базой данных, то в первую очередь влияет размер памятии пропускная способность каналов ввода-вывода. Хотя RAM на мф образует RAIM, т.е. на самом деле каждый байт хранится в нескольких экземплярах, на в обном байте мф памяти хранится восемь информационных битов, так же как и в памяти HP DLxxx и за каждым байтом надо лезть на диски и пропускать этот байт через те каналы, которые развивают разную скорость пропускания битов. Ну и ты не будешь спорить ведь что в 1TB помещается в 128 раз больше данных чем в 8 GB и если данные запрашиваются повторно и их еще не прекрыли новые данные, а такая вероятность всегда есть, и в случае бОльшей памяти вероятность перекрытия данных другими снижается и лезть на диски становится не нужным вообще.
На самом деле мне этот тест как раз показывает насколько же на самом деле мф лучше может распоряжаться наличными ресурсами что даже в такой сильно выигрышной для х8 по мощности ситуации мф не сильно проиграл. Случай с одним пакетным задание можно вынести за скобки - одно задание это вообще не тест. Т.е. предположение что 80 корый и 1 TB МФ разорвал бы НР DLxxx в лоскуты, согласен?

Сокеты операционной системе вообще как бы не важны. Но на мф действительно это учитывается определенным образом. Интересно в ОС для х86 тоже? На машинах с большим количеством коров это учитывать сложнее (если конечно это учитывается).
Меряться можно и не конечными машинами, но делать это надо аккуратно, не обманывая себя. Я предлагал схемы, но мы об этом можем только говорить здесь без выхлопа.

Жаль что ты железячник и некоторые аспекты систем и баз данных не ощущаешь полностью. Дима, от разговора дистанцировался, другие тоже. Тем не менее спасибо тебе за попытку и согласие что обсуждаемый тест не презентативен ни для чего того что декларируется как выводы. У тебя это был список мифов и реальностей где то в начале темы.

[Dmitry67]

Я не дистанцировался, просто выходные

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

С тем же MS SQL я могу чуть забашлять Амазону и через полчаса получить машинку на поиграться. Где я могу поиграться с МФ? Вот вы бы хотели раскрыть студентам прелести МФ, соблазнить их так сказать))). И знаете как это придется делать? Мелом на доске. Как в моем далеком студенчестве, когда я был от 30ки между 9 и 10 классом на практике в университете. Мы писали на Паскале не в редакторе, а мелом на доске две недели. А машинное время нам так и не дали)))

[zVlad]

Я не дистанцировался, просто выходные

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

С тем же MS SQL я могу чуть забашлять Амазону и через полчаса получить машинку на поиграться. Где я могу поиграться с МФ?

Дима, но мы же с flip_flop обсуждаем уже проделанную работу по сравнению разных платформ. Нам не надо самим добывать мф, добывать х86 сервера, писать одинаковые транзакции на одинаковые по структуре и, я надеюсь, объемы баз данных, замерять результаты. Все это за нас сделали. Теперь мы может все что было сделано и сведено в отчет обсудить.
По сути конечно обсудить отчет и то как устроители организовали свои испытания, но это же тоже основа для научного анализа. Физики вон строят гигантские коллайдеры, гоняют там потоки частиц ждут когда они соударятся и им удастся что-нибудь увидеть и померять и им удается делать открытия которых никто не знал.
В нашем то случае все намного проще. Все параметры известны и есть результаты одинаковых нагрузок. Что нам не хватает кроме этого и критического мышления чтобы увидеть где мухи а где котлеты?

Я посмотрю понравившееся тебе исследование, но я наперед знаю что они там сравнивали одни и те же яица. Примерно как ай- и ан- (кстати я обоими руками за ан-). Рискую конечно ошибиться, но мне терять то нечего.

P.S. Физики почему то не просят матушку-природу выполнять процессы помедленнее, и чтобы частицы были покрупнее, а то их трудно изучать.
У нас то все рукотворное, сами мы, люди, все это придумали и сделали. А мы здесь на форуме никак не можем понять почему золото дороже железа в то время как и то и другое металы. Парадокс!

[mskmel]

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

У них данных 800МБ, там не экзадату или МФ, а то что именно они сделали - кастомный продукт на C\C++
Индивидуально запиленный инструмент всегда победит generic решение.

[Dmitry67]

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

У них данных 800МБ, там не экзадату или МФ, а то что именно они сделали - кастомный продукт на C\C++
Индивидуально запиленный инструмент всегда победит generic решение.

Ну тестировали они на маленьком примере
Но поинт то не в том
Как мне пожамкать руками exadata или МФ?

[zVlad]

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

У них данных 800МБ, там не экзадату или МФ, а то что именно они сделали - кастомный продукт на C\C++
Индивидуально запиленный инструмент всегда победит generic решение.

Ну тестировали они на маленьком примере
Но поинт то не в том
Как мне пожамкать руками exadata или МФ?

МФ не девушкам - руками его не пожамкаешь
Дима, ты ж читать умеешь. Прочти внимательно то что приводил flip_flop в начале тобой же открытой темы и взяв референс на документ упоминавшийся в тобой же приведенной ссылке. Там пишут о том как они жамкали МФ, какой МФ, чем жамкали - там все есть, правда это надо критически анализировать потому что приемы их умозаключений не чистые и не корректные.

Ты замутил эту дискуссию (драку) и сам же спрятался в кустах. Не солидно поступаешь.

[mskmel]

Но поинт то не в том
Как мне пожамкать руками exadata или МФ?

https://cloud.oracle.com/en_US/cost-estimator
Data Management
Oracle Database Exadata Express Cloud Service
поиграться с ценой. Судя по всему в несколько сотен в год вложиться можно с чем то очень маленьким Только не понятен смысл "пожмакать". Без storage server это обычный 2х сокетный сервер, с ожидаемой производительность. Storage server на минимальных 20ГБ даты смысла великого не имеет.
В теории можно поднять storage server у самого себя, понятно что скорости будут не те, но на "пожмакать" хватит.

[Dmitry67]

Прочти внимательно то что приводил flip_flop в начале тобой же открытой темы и взяв референс на документ упоминавшийся в тобой же приведенной ссылке. Там пишут о том как они жамкали МФ, какой МФ, чем жамкали - там все есть, правда это надо критически анализировать потому что приемы их умозаключений не чистые и не корректные.

Вы серьезно предлагаете мне ДОКУМЕНТ вместо реального доступа к машине?
Это все равно что предложить журнал с картинками вместо реальной девушки)
Конечно, и с журналом кое чего можно достичь, но это не то чего хочется

[zVlad]

Прочти внимательно то что приводил flip_flop в начале тобой же открытой темы и взяв референс на документ упоминавшийся в тобой же приведенной ссылке. Там пишут о том как они жамкали МФ, какой МФ, чем жамкали - там все есть, правда это надо критически анализировать потому что приемы их умозаключений не чистые и не корректные.

Вы серьезно предлагаете мне ДОКУМЕНТ вместо реального доступа к машине?
Это все равно что предложить журнал с картинками вместо реальной девушки)
Конечно, и с журналом кое чего можно достичь, но это не то чего хочется

Не, Дима, тут совсем другое. Ну дадут тебе МФ и что ты с ним делать то будешь? Эту девушку тебе все равно не станцевать.
Так что читай журнал если конечно всерьез хочешь что-то понять и обсудить, а не для разговора ни о чем.

[Dmitry67]

Не, Дима, тут совсем другое. Ну дадут тебе МФ и что ты с ним делать то будешь? Эту девушку тебе все равно не станцевать.
Так что читай журнал если конечно всерьез хочешь что-то понять и обсудить, а не для разговора ни о чем.

То есть вы ходите сказать, что те ребята, которые играючи подцепили под свою задачу 10 разных баз для сравнения, с МФ не справятся или залипнут на месяцы? Кому нужна система с таким большин уровнем вхождения....

[Boriskin]

По поводу процессоров и их скорости - не стоит принижать ни современные процессоры для z14 МФ ("бегут очень медленно") ни современные х86 процессоры ("застой где-то с 201х года"). Ни то, ни другое не отражает действительности. Я могу очень детально привести аргументы с точки зрения микроэлектроники и немного с точки зрения низкоуровневой архитектуры, но боюсь никому не будет интересны такие детали.

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

[mskmel]

А там что под лозунгом "так принято" ввод-вывод зажали до 2 Gb/sec против 8 Gb/sec.
...
Ну и ты не будешь спорить ведь что в 1TB помещается в 128 раз больше данных чем в 8 GB и если данные запрашиваются повторно и их еще не прекрыли новые данные

Узким местом каналы к дискам, и вообще производительность БД, там не были, пруфы:
- рост латентности транзакции на Z при достижении 95% CPU - 7 страница первый абзац и график на 11
- почти вся нагрузка от app server - page 9
- несущественное увеличение TPS когда БД убрали с DL980 на другой сервер - табличка на стр 10

[zVlad]

Не, Дима, тут совсем другое. Ну дадут тебе МФ и что ты с ним делать то будешь? Эту девушку тебе все равно не станцевать.
Так что читай журнал если конечно всерьез хочешь что-то понять и обсудить, а не для разговора ни о чем.

То есть вы ходите сказать, что те ребята, которые играючи подцепили под свою задачу 10 разных баз для сравнения, с МФ не справятся или залипнут на месяцы? Кому нужна система с таким большин уровнем вхождения....

Те ребята (я их не знаю конечно и могу ошибаться) счастливы тем что они знают и умеют. На предложение освоить что-нибудь по МФ они ничего кроме круглых глаз предявить не смогут. Заниматься надо тем что нужно. Вот и тебе совершенно не хочется читать готовый материал по теме которую ты (все таки ты, не я и не flip_flop) зачем то открыл.

Но те же самые ребята (или даже ты) попав в определенную среду и обстоятельства легко изучат и будут работать не только на МФ, но и например на балалaйке, или самосвале. Люди не рождаются для чего-то одного, например, для Маков.

Я только что созванивался с твоим коллегой - MS SQL DBA, работающим у нас и поддерживающим реплику с моего DB2. Хотел обсудить с ним один маловажный вопрос связанный с той аппликухой, которая стоит на его сервере и занимается репликацией и с которой я работаю с легкой руки моей предшественницы ушедшей на пенсию, которая из любопытства перетянула эту работу в нашу группу, и которую я скоро буду передавать тому MS SQL DBA.
Его звать Сергей и он, как обычно, сказал что ужасно занят и перезвонит после обеда. Но знаю что он не перезвонит и поэтому сказал ему не беспокоится и забыть.
Я знаю почему таким ребятам нравится работать не на МФ - им нравится быть все время "занятыми". А вот у меня масса свободного времени в офисе. В то же время я уже с утра два запроса выполнил.

[zVlad]

А там что под лозунгом "так принято" ввод-вывод зажали до 2 Gb/sec против 8 Gb/sec.
...
Ну и ты не будешь спорить ведь что в 1TB помещается в 128 раз больше данных чем в 8 GB и если данные запрашиваются повторно и их еще не прекрыли новые данные

Узким местом каналы к дискам, и вообще производительность БД, там не были, пруфы:
- рост латентности транзакции на Z при достижении 95% CPU - 7 страница первый абзац и график на 11
- почти вся нагрузка от app server - page 9
- несущественное увеличение TPS когда БД убрали с DL980 на другой сервер - табличка на стр 10

Ну наконец то хоть что-то внятное и по делу. Дождался.

Старница 7 про транзакции (OLTP), а странице 9 про batch, который кстати в этой работе для z представлен прогoнами одного задания zRefBR, и двух заданий zRefBU - на МФ никогда так не делают. Даже если МФ имеет только пакетную загрузку то это спроектираванно так чтобы CPU byl 100% busy 24 hours. У нас был такой mainframe, я правда на нем не работал - соседский. У нас же пакетные задания выполняются 24*7 по schedule тогда когда это надо, некоторые запускаются, скажем, каждые 10 минит другие 15 минут и т.д. И все это в параллель с 24*7 OLTP.

Вернемся, однако, к OLTP на странице 7. Как раз то что latency стал расти не достигнув 100% CPU busy и говорит, с очевидностью, о том что начался bottleneck где то в вводе-выводе или памяти (или и там и там). Нам не показали ни страничного обмена, который идет на те же самые диски по тем же самым каналам (других нет) где и БД находится, ни загрузки ввода-вывода. Мне бы очень хотелось хотя бы увидеть вот этот параметр:

Code: Select all

_______Field_______          __Value__
Unreferenced Intvl Cnt           22188

Насколько бы увеличился TPS если бы они сумели нагрузить CPU do 100% - а это вполне нормально для z/OS - устранением bottleneck сказать невозможно, но я бы ожидал приличного роста, именно либо от увеличения RAM, либо от подключения дисков хотя бы не через switch-и, что в работе отнесено как обычной практике, но я с этим категорически не согласен - обычно диски подключают напрямую к FICON.
Резюме: МФ даже в том для чего тест делали - сравнить MIPS-ы CPU - не был нагружен и причина была не в CPU. Вот в чем беда этого теста.
И я еще раз повторю именно 95% CPU показывает наличие проблемы в другом, не CPU, месте. Вы с этим согласны?

[Flash-04]

У тебя интересные конечно возражения. Я помню как в свое время воевал за то чтобы получить к приложению жадному до I/O (с Oracle внутри) специальный SSD сторидж на 4 Tb с подключением через fiber channel. Приложение ессно бегало на x86 и задыхалось под нагрузкой. В итоге денег на сторидж не дали, приложение мигрировали на более мощный сервер и к тому времени у нас уже появились shared EMC2 SSD сториджи, и стало бегать существенно бодрее. Затык был именно в системе ввода-вывода потому что из диагностики было хорошо видно что процессоры простаивпют в ожидании и когда закончатся операции чтения-записи.
К чему это я? А к тому что получается x86 ни причём, а причём обвязка из внешних систем. Собсно Влад, твои аргументы выглядят примерно так же - "вам не нравятся кошки, потому что вы их не умеете готовить"

Я знаю людей который ту же самую систему с Ораклом ставили на спец железо от Оракла и получали просто фантастическую производительность. И заметьте, без мейнфрейма.

[zVlad]

....
К чему это я? А к тому что получается x86 ни причём, а причём обвязка из внешних систем. Собсно Влад, твои аргументы выглядят примерно так же - "вам не нравятся кошки, потому что вы их не умеете готовить"

Я знаю людей который ту же самую систему с Ораклом ставили на спец железо от Оракла и получали просто фантастическую производительность. И заметьте, без мейнфрейма.

Нет у меня таких аргументов. Я четко указал на причины почему по моему (а у меня в этом большой опыт) МФ в этом тесте выглядит ниже своих возможностей, используя общепринятые и понятные обяснения (я не говорил про не умение готовить кошек). То что ты привел из своего опыта это один в один то о чем я говорю только кроме ввода-вывода в этом случае еще и с размером RAM явно погоречились. Причем я не говорил даже оо выравнивании параметров используемог х86 с аналогичными на МФ. Память в 32 GB и прямое, без switches, подключение дисков к FICON могут изменить картину в разы с тем же LPAR что в HP test достигнуто. Я сказал что-нибудь о кошках, или о не умении их готовить?
x86 пока не причем. В тесте HP использованны на то время реально супермощные сервера. МФ же был взят махонький да еще и с зажатыми параметрами.
Фантастической производительности не бывает, бывает та которую можно достичь на оборудовании определенной производительности. МФ могут быть малехонькие и реально гигантские (фантастические). И их результаты соответственно тоже будут разными. Никому не нужна абстрактная фантастическая производительность. Нужна та что удовлетворяет потребности. Это довольно не простая задача - right sizing. Да, за ней, из-за дешевизны, на х86 не гоняются, но это временно.
На мой взгляд как раз в клаудах начнется понимание что выстаивание рядов стоек с тысячами х86 серверов и их недогруз не есть хорошо. A поскольку пользователям нужны сервисы, а не сервера x86, то и подменить сервера будет не сложно - никто не заплачет если вместо х86 результат им даст тот или иной МФ, или что вероятней гибридная установка из МФ и x86 (Xeon) блэйдс - zBX: https://www.theregister.co.uk/2011/01/1 ... bx_update/ Этой истории уже больше 7 лет..

[Dmitry67]

и их недогруз не есть хорошо.

Недогруз...
Все таки МФ калечит сознание

90_full.jpg

[Flash-04]

Влад, какой недогруз на серверах которые суть виртуализируюшие сервера? Нет такой проблемы.

[Flash-04]

Кстати, Дмитрий, а что там с загонянием Oracle в VM? Я помню был период когда нам крайне не рекомендовали пихать БД в VM, но у нас был очень busy экземпляр. Вроде уже переросли эту проблему?

[zVlad]

Влад, какой недогруз на серверах которые суть виртуализируюшие сервера? Нет такой проблемы.

Виртуализация это не волшебная палочка. На МФ это давно уже переросли и преодолели. Все стоит на реальных ресурсах сколько бы поклонов слову "виртуализация" мы бы не отбивали, которые могут быть либо эффективно загружены либо недогружены. Третье это загруженность бессмысленной работой, в частности виртуализацией, издержки которой выполняются на реальных ресурсах.
P.S. Погода то какая мерзкая, а? В субботу лечу в Punta Cana.

[Flash-04]

Погода ужасная. Приятного отдыха

Влад, тебе не кажется что ты какую то бессмысленную фразу выдал про "реальные ресурсы"?