Демократизация мейнфреймов

[zVlad]

Вот диски для МФ:

хттп://шшш-03.ибм.цом/сыстемс/стораге/диск/дс8000/индех.хтм

Суппорт фор 2 то 32 хост адаптерс анд уп то 128 Фибре Чаннел/ФИЦОН® хост портс

Впечатляет, да.

Сколько процессоров подразумевает МФ, который может использовать такую дисковую систему в максимальной конфигурации? Какая скорость передачи данных (датарате) у ФИЦОН?

В принципе, сервер с таким же уровнем поддержки ФЦ тоже можно собрать (можно и больше наагрегировать, в принципе :Д ), не уверен правда нужно ли и как это дело максимально использовать.

ФИЦОН Ехпресс8 - 8 Гб/с . Максимальные кофигурации делаются индивидуально и, как я полагаю, не априори, а по мере надобности. К нашему 5-ти процессорному МФ дисковая подсистема подключена 6-тью каналами ФИЦОН Ехпресс4 - 4 Гб (всего у нас 16 ФИЦОН портов) и они не сильно загружены. Для нашей конфигурации количество каналов в первую очередь определяется требованиями реданденси и распарралеливанием ввода-вывода. Дело в том что операции ввода-вывода могу выполняться по любому из доступных каналов. Все диски доступны по любому каналу тоже. Система находит незанятый канал и назначает его для ввода-вывода. Таким образом осуществляется мультипроцессирование ввода-вывода подобно мультипроцессированию центральных процессоров.

Ага, спасибо. Для серверов примерно то же самое можно делать, по крайней мере наше хардшаре так позволяет.

Что значит "по крайней мере"? А система?

[flip_flop]

Ага, спасибо. Для серверов примерно то же самое можно делать, по крайней мере наше хардшаре так позволяет.

Что значит "по крайней мере"? А система?

ОС? Должна, но могу только догадываться. Прошу помощи зала

[zVlad]

Ага, спасибо. Для серверов примерно то же самое можно делать, по крайней мере наше хардшаре так позволяет.

Что значит "по крайней мере"? А система?

ОС? Должна, но могу только догадываться. Прошу помощи зала :хат:

Пока зал собирается я повторю здесь информацию предоставленную iDesperado, где я выделил заинтеросовавший меня момент, который безответно просил прокомментировать. Может Вы прокомментириете. Это хард.

2zVlad
если хочеться чего-то конкретного, пожалуйста
http://www.tpc.org/results/FDR/tpce/HP. ... 01.fdr.pdf

4 сокета, 40 ядер, терабайт рама, 11 дополнительных контроллеров по 4 порта в каждом:
The P812 controllers each have 4 data ports. Each data port was connected to a single D2700 Disk enclosure with 25 x 72GB 15K RPM SFF SAS disks, for a total of 4 enclosures per P812.
всего 1100 15К дисков. все это счастье, вместе с софтом чуть дороже 1/4 стоимости МФ с 10 ядрами и 258 гб рама и без дисковой субсистемы.

[iDesperado]

Чтобы не бытьголословным я укажу на факт что в случае с МФ потоков заданий было всего восемь, в то время как на сантехнике 32. Почему? Почему хотя бы не одинаково. А если запустить 64 потока на МФ.

ну это очевидно, потому что у МФ всего 8 ядер на задачу отвели. 64 потока бы лишь увеличили время т.к. ко времени выполнения добавилось бы еще и переключение потоков, борьба за ресурс. собственно по этому именно 32 на сантехнике и именно 16 на итаниуме.

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

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

Пока зал собирается я повторю здесь информацию предоставленную iDesperado, где я выделил заинтеросовавший меня момент, который безответно просил прокомментировать. Может Вы прокомментириете. Это хард.

все очень просто: в тестах tpc указывается цена, для того что бы снизить цену вендоры для таких тестов берут самые дешевые стойки. вместо 44 дешевых они без проблем могли бы подключить пару DS8800, но цена транзакции взлетела бы до неприличных высот, а система бы опустилась в топе price/performance.

[zVlad]

Чтобы не бытьголословным я укажу на факт что в случае с МФ потоков заданий было всего восемь, в то время как на сантехнике 32. Почему? Почему хотя бы не одинаково. А если запустить 64 потока на МФ.

ну это очевидно, потому что у МФ всего 8 ядер на задачу отвели. 64 потока бы лишь увеличили время т.к. ко времени выполнения добавилось бы еще и переключение потоков, борьба за ресурс. собственно по этому именно 32 на сантехнике и именно 16 на итаниуме.

....

Да видимо так и думали оракловце планирующие тест. Но это полная херня. Что получается что в случае одного процессора может выполняться только одна задача?
Махровое невежество пошло. Количество процессоров вовсе не ограничивает количество одновременных заданий. Это было бы не так только в одном случае - когда процессор задействован и для вычислений и для ввода-вывода. Да и в этом случае общее время выполнения всех заданий равнялось был сумме времен выполнения каждого. Оно могло бы уменьшится только если бы не 8, а например 6 заданий одновременно выполнялись бы.
Неужели Вы будете спорить и сейчас?

[crypto5]

Чтобы не бытьголословным я укажу на факт что в случае с МФ потоков заданий было всего восемь, в то время как на сантехнике 32. Почему? Почему хотя бы не одинаково. А если запустить 64 потока на МФ.

ну это очевидно, потому что у МФ всего 8 ядер на задачу отвели. 64 потока бы лишь увеличили время т.к. ко времени выполнения добавилось бы еще и переключение потоков, борьба за ресурс. собственно по этому именно 32 на сантехнике и именно 16 на итаниуме.

....

Махровое невежество пошло. Количество процессоров вовсе не ограничивает количество одновременных заданий.

Не ограничивает, но как уже написали выше вносит оверхед на переключения между потоками/процессами.

[zVlad]

....

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

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

....

Про ввод-вывод МФ в отчете ровным счетом ничего не сказано. Для Вас, поскольку ввод-вывод для Вас - это количество шпинделей, может и сказано все. Мне нужно знать сколько и какие каналы использовались для дисков. Мне вообще много чего не хватает в отчете чтобы составуть полную картину выполнения теста на МФ.
Да и роль численного преимущества как-то не пропорционально проявилась. 50 минут отличается от 59 минут на ~16% всего, а преимущество в разы.

[iDesperado]

Да видимо так и думали оракловце планирующие тест. Но это полная херня. Что получается что в случае одного процессора может выполняться только одна задача?
Махровое невежество пошло. Количество процессоров вовсе не ограничивает количество одновременных заданий. Это было бы не так только в одном случае - когда процессор задействован и для вычислений и для ввода-вывода. Да и в этом случае общее время выполнения всех заданий равнялось был сумме времен выполнения каждого. Оно могло бы уменьшится только если бы не 8, а например 6 заданий одновременно выполнялись бы.
Неужели Вы будете спорить и сейчас?

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

[zVlad]

Чтобы не бытьголословным я укажу на факт что в случае с МФ потоков заданий было всего восемь, в то время как на сантехнике 32. Почему? Почему хотя бы не одинаково. А если запустить 64 потока на МФ.

ну это очевидно, потому что у МФ всего 8 ядер на задачу отвели. 64 потока бы лишь увеличили время т.к. ко времени выполнения добавилось бы еще и переключение потоков, борьба за ресурс. собственно по этому именно 32 на сантехнике и именно 16 на итаниуме.

....

Махровое невежество пошло. Количество процессоров вовсе не ограничивает количество одновременных заданий.

Не ограничивает, но как уже написали выше вносит оверхед на переключения между потоками/процессами.

Где, кто написал? Какой оверхед? А простой пороцессора в ожидании работы это как называется? Я уверен что с 8 пакетными заданиями процессоры МФ существенно простаивали в ожидании ввода-вывода, про который мы ничего не знаем кстати.
Переключение задач на МФ и на других платформах это очень разные вещи. Количество выполняемых задач это тоже не количество запущенных пакетных заданий, тем более если речь идет о приложении ДБ2, а не о тестовом подсчете нулей в памяти..

[zVlad]

Да видимо так и думали оракловце планирующие тест. Но это полная херня. Что получается что в случае одного процессора может выполняться только одна задача?
Махровое невежество пошло. Количество процессоров вовсе не ограничивает количество одновременных заданий. Это было бы не так только в одном случае - когда процессор задействован и для вычислений и для ввода-вывода. Да и в этом случае общее время выполнения всех заданий равнялось был сумме времен выполнения каждого. Оно могло бы уменьшится только если бы не 8, а например 6 заданий одновременно выполнялись бы.
Неужели Вы будете спорить и сейчас?

"Махровое невежество" :лол:
вы там себя хорошо чувствуете ? лекарства сегодня не принимали ? вы представляете какие программы были задействаны были в тесте, где были "потоки", как потоки соотносятся с процессами на апп-сервере, с процессами субд. вы действительно думали, что 8 потоков это 8 процессов :фоол: ?

Это Вам надо лекарства принимать, а лучше прежде чем говорить поинтересоваться есть ли на МФ потоки и процессы и если есть то как ими управлыют. А не задавать идиотские вопросы после того как сами же написали:

ну это очевидно, потому что у МФ всего 8 ядер на задачу отвели

[crypto5]

Чтобы не бытьголословным я укажу на факт что в случае с МФ потоков заданий было всего восемь, в то время как на сантехнике 32. Почему? Почему хотя бы не одинаково. А если запустить 64 потока на МФ.

ну это очевидно, потому что у МФ всего 8 ядер на задачу отвели. 64 потока бы лишь увеличили время т.к. ко времени выполнения добавилось бы еще и переключение потоков, борьба за ресурс. собственно по этому именно 32 на сантехнике и именно 16 на итаниуме.

....

Махровое невежество пошло. Количество процессоров вовсе не ограничивает количество одновременных заданий.

Не ограничивает, но как уже написали выше вносит оверхед на переключения между потоками/процессами.

Где, кто написал? Какой оверхед?

Выше Десперадо написал.

А простой пороцессора в ожидании работы это как называется? Я уверен что с 8 пакетными заданиями процессоры МФ существенно простаивали в ожидании ввода-вывода, про который мы ничего не знаем кстати.

Откуда вы знаете что существенно простаивали? ПРиведите или сделайте хотя бы один "правильный" бенчмарк где МФ выигрывают.

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

Конечно-конечно, опять начинаются сказки про магические свойства мейнфреймов.

[zVlad]

....

А простой пороцессора в ожидании работы это как называется? Я уверен что с 8 пакетными заданиями процессоры МФ существенно простаивали в ожидании ввода-вывода, про который мы ничего не знаем кстати.

1. Откуда вы знаете что существенно простаивали? ПРиведите или сделайте хотя бы один "правильный" бенчмарк где МФ выигрывают.

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

2. Конечно-конечно, опять начинаются сказки про магические свойства мейнфреймов.

1. Это хотя бы из отчета видно, из таблицы загрузку процессора.

2. А Вы поизучайте сами эту тему тогда и не будете относится к тому что не укладывается в ВАши представления как к сказкам. Это не сложно. Задумайтесь например о том почему у МФ процессора нет параметра threads.

[iDesperado]

Где, кто написал? Какой оверхед? А простой пороцессора в ожидании работы это как называется? Я уверен что с 8 пакетными заданиями процессоры МФ существенно простаивали в ожидании ввода-вывода, про который мы ничего не знаем кстати.

процессоры МФ с 8 потоками были заняты на 67%-78%. вы на полном серьезе полагаете, что 64 потока увеличили бы производительность ?

Это Вам надо лекарства принимать, а лучше прежде чем говорить поинтересоваться есть ли на МФ потоки и процессы и если есть то как ими управлыют. А не задавать идиотские вопросы после того как сами же написали:

ну извините, я же не предполагал, что вы на столько глубокими знаниями обладаете, что сможете заподозрить, что потоки как-то могли быть связанны с процессами оси. оракл стартуя процессов 30 плодит сразу, причем одна коннекция в процессе исполнения, например чтений партиций, на каждую партицию отдельный юзерский процесс пускает

[zVlad]

Где, кто написал? Какой оверхед? А простой пороцессора в ожидании работы это как называется? Я уверен что с 8 пакетными заданиями процессоры МФ существенно простаивали в ожидании ввода-вывода, про который мы ничего не знаем кстати.

процессоры МФ с 8 потоками были заняты на 67%-78%. вы на полном серьезе полагаете, что 64 потока увеличили бы производительность ?

....

Производительность заданого компьютера величина постоянная и неизменная. Время выпонения всего теста уменьшили бы несомненно. Ведь есть же еще запас в 33%-22%. Только не надо делать круглые глаза и говорить что при 100% загрузки все остановится.

[iDesperado]

Производительность заданого компьютера величина постоянная и неизменная. Время выпонения всего теста уменьшили бы несомненно. Ведь есть же еще запас в 33%-22%. Только не надо делать круглые глаза и говорить что при 100% загрузки все остановится.

именно этот запас и дает мне возможность оценить на сколько адекватна была настроена дисковая субсистема, совершенно не вникая в подробности конфига. 8 потоков МФ сумели "прокормить" процессоры грубо говоря на 70%. лично мне совершенно очевидно что даже 16 потоков если не в и/о упрется, то гарантированно упрется в процессоры МФ. далее наращивая кол-во потоков мы лишь увеличиваем конкуренцию за горячий ресурс и соответственно оверхед на обслуживание.
теперь смотрим на сантехнику - 32 потока лишь 44% на пике, т.е. запас по cpu почти двухкратный, в сравнении с МФ.

[zVlad]

Производительность заданого компьютера величина постоянная и неизменная. Время выпонения всего теста уменьшили бы несомненно. Ведь есть же еще запас в 33%-22%. Только не надо делать круглые глаза и говорить что при 100% загрузки все остановится.

именно этот запас и дает мне возможность оценить на сколько адекватна была настроена дисковая субсистема, совершенно не вникая в подробности конфига. 8 потоков МФ сумели "прокормить" процессоры грубо говоря на 70%. лично мне совершенно очевидно что даже 16 потоков если не в и/о упрется, то гарантированно упрется в процессоры МФ. далее наращивая кол-во потоков мы лишь увеличиваем конкуренцию за горячий ресурс и соответственно оверхед на обслуживание.
теперь смотрим на сантехнику - 32 потока лишь 44% на пике, т.е. запас по cpu почти двухкратный, в сравнении с МФ.

Вам, с Вашими знаниями МФ, я бы посоветовал не торопиться с умозаключениями по поводу тестов выполненых одним давним компетиром на инфраструктуре другого.
Я могу назвать несколько причин чем, кроме полезной работы, может быть загружен CPU МФ и как от этого оверхеда можно элементарно избавиться. Более того мне уже приходилось критиковать Оракловский вариант тестирования с участием DB2 в конце 90-х. Я лично контактировал тогда с отделением Оракл в Москве. А делали они тестирование для МЖД и сравнивали они DB2, Oracle и Adabas. Победил конечно Оракл. Но в личной беседе когда я их спросил о некоторых вещах в DB2, которые обычно выключаются если это продакшн, оракловец согласился что в их тестах это не было сделано. Касается это сбора информации о работе DB2. Есть много уровней, среди которых есть такой который позволяет выявлять проблемы производительности и используется для соответствующих целей. Это уровень создает весьма существенный оверхед. Был он выключен в этих тестах? Никто не знает. Есть и менее существенные побочные процессы системы которые могут тем не менее грузить CPU без пользы для собственно выполнения работы. Такие процессы следует выключать в подобных тестах. Об этом в отчете нет ни слова.

Что касаемо Вашего скорее эмоционального чем имеющего отношение к реальности рассуждения о "конкуренции за горячий ресурс" вызванный квеличением количества конкурирующих процессов, то это все от Вашего незнания как поступает ОС МФ в таких ситуациях. А поступает она так что постоянно измеряет оверхед ассоциированный с переключением задач (на МФ это называется задача - task) и когда оверхед превышает некий разумный уровень то часть задач временно, до понижения оверхеда, не обслуживается. Таким образом ОС МФ можно грузить работой без опасений что она загнется. Индикатором что МФ загружен полность является показание загрузки CPU - 99.9%. Только при таком значении можно сказать что МФ загружен полностью. Все рассуждения о том сколько потоков может выдержать МФ а сколько нет - пустая болтовня пока мы не фиксируем такое значение загрузки CPU.

Пример из жизни. Один из наших клиентов имеет пакетную систему биллинга за электроэнергию всей провинции Онтарио. Это практически непрерывный поток заданий 24 часа в сутки. Они гоняют задания 24 часа в сутки по стольку по скольку надо не озираясь на количество CPU (см. ниже). Все у них выполняется к заданному сроку. Они специально пришли к такому режиму чтобы иметь самый маломощный и соответственно дешевый из возможных МФ. И этим МФ оказался МФ с двумя CPU 214 MIPS-ами на котором кроме продакшн еще два LPAR-а есть с непродакшн системами, и у продакшн 3 GB RAM из 6 и гарантированные 80% мощности CPU. Остальные 20% гарантированны для других двух систем на этом же МФ.

[Zombie416]

Пример из жизни. Один из наших клиентов имеет пакетную систему биллинга за электроэнергию всей провинции Онтарио. Это практически непрерывный поток заданий 24 часа в сутки. Они гоняют задания 24 часа в сутки по стольку по скольку надо не озираясь на количество CPU (см. ниже). Все у них выполняется к заданному сроку. Они специально пришли к такому режиму чтобы иметь самый маломощный и соответственно дешевый из возможных МФ. И этим МФ оказался МФ с двумя CPU 214 MIPS-ами на котором кроме продакшн еще два LPAR-а есть с непродакшн системами, и у продакшн 3 GB RAM из 6 и гарантированные 80% мощности CPU. Остальные 20% гарантированны для других двух систем на этом же МФ.

"Биллинг за электроэнергию всей провинции Онтарио" - это много или мало? Если прикинуть масштаб, то в худшем случае аж 10 миллионов потребителей, с пусть 2-3 показаниями счетчика в месяц (реально меньше). Т.е. надо обработать, как максимум, аж 30 миллионов событий в месяц, или ~10 в секунду. Естессно хватит и маломощного компьютера. Да, в начале 90х, или когда там эта система дизайнилась, МФ был бы естественным выбором для такого дела. Сейчас - лаптоп справится.

Только причем этот пример к серьезным нагрузкам и тестам?

[zVlad]

Пример из жизни. Один из наших клиентов имеет пакетную систему биллинга за электроэнергию всей провинции Онтарио. Это практически непрерывный поток заданий 24 часа в сутки. Они гоняют задания 24 часа в сутки по стольку по скольку надо не озираясь на количество CPU (см. ниже). Все у них выполняется к заданному сроку. Они специально пришли к такому режиму чтобы иметь самый маломощный и соответственно дешевый из возможных МФ. И этим МФ оказался МФ с двумя CPU 214 MIPS-ами на котором кроме продакшн еще два LPAR-а есть с непродакшн системами, и у продакшн 3 GB RAM из 6 и гарантированные 80% мощности CPU. Остальные 20% гарантированны для других двух систем на этом же МФ.

"Биллинг за электроэнергию всей провинции Онтарио" - это много или мало? Если прикинуть масштаб, то в худшем случае аж 10 миллионов потребителей, с пусть 2-3 показаниями счетчика в месяц (реально меньше). Т.е. надо обработать, как максимум, аж 30 миллионов событий в месяц, или ~10 в секунду. Естессно хватит и маломощного компьютера. Да, в начале 90х, или когда там эта система дизайнилась, МФ был бы естественным выбором для такого дела. Сейчас - лаптоп справится.

Только причем этот пример к серьезным нагрузкам и тестам?

Этот биллинг крутится на МФ которые я не обслуживаю. Поэтому я не могу рассказать из чего состоит этот расчет и каковы его параметры сложности.

Привел я этот пример к тому что я сильно сомневаюсь в правильной настройке DB2 и zOS в тесте представленном Оракл. У меня для этого есть основания, в том числе и этот пример из жизни.

Оракловский тест на PeopleSoft-е тоже ведь не расчет траектории полета к Марсе и обратно или что там для Вас серьезной нагрузкой считается. А 6 с лишним тысяч MIPS - это хорошая моща. Мы, имея лишь одну тысячу MIPS крутим ERP приложение для клиента с более чем 10000 работников, БД более 1 TB и аппликэйшн OLTP сервером. Это приложение у клиента основное в их ИТ. Плюс многие другие приложения не на МФ либо непосредственно обращаются к МФ БД, либо используют онлайн реплику БД, apply часть которой на том же МФ выполняется. Т.е. это целая комплескная инфраструктура и все на одном МФ с 1000 MIPS и девелопмент и QA и трэйниг и сандбохы, т.е. абсолютно все кроме DR.

[flip_flop]

[Ага, спасибо. Для серверов примерно то же самое можно делать, по крайней мере наше хардшаре так позволяет.]

Что значит "по крайней мере"? А система?

ОС? Должна, но могу только догадываться. Прошу помощи зала :хат:

Пока зал собирается я повторю здесь информацию предоставленную иДесперадо, где я выделил заинтеросовавший меня момент, который безответно просил прокомментировать. Может Вы прокомментириете. Это хард.

[2zVlad
если хочеться чего-то конкретного, пожалуйста
http://www.tpc.org/results/FDR/tpce/HP. ... 01.fdr.pdf

4 сокета, 40 ядер, терабайт рама, 11 дополнительных контроллеров по 4 порта в каждом:
Тхе П812 цонтроллерс еач хаве 4 дата портс. Еач дата порт шас цоннецтед то а сингле Д2700 Диск енцлосуре шитх 25 х 72ГБ 15К РПМ СФФ САС дискс, фор а тотал оф 4 енцлосурес пер П812.
всего 1100 15К дисков. все это счастье, вместе с софтом чуть дороже 1/4 стоимости МФ с 10 ядрами и 258 гб рама и без дисковой субсистемы.]

Интересно, как транслит преобраует вежливого джентлемена в злую красную морду
Честно говоря, я не вижу ужаса и предмета для комментирования. На сервере контроллер отображения PCIe Gen2 в четыре порта SAS Gen2(6 GT/s) - обычный стандарт. На дисковой стойке (или как там оно называется?) стоит другой конец SAS с той же скоростью. И чему тут удивляться? SAS - почти тот же FC по скорости, только дешевле. Не знаю как супротив FICON по степени "умности" (SAS достаточно архитектурно развитый по сравнению с дешевым [SATA], например), только SAS дешевле, много дешевле . И SAS - открытый, универсальный стандарt.

А вот почему нельзя использовать тестбенчи tpc-e в качестве стандарта меряния производительностью для задач класса МФ? Можно прокомментировать #1 от [NEC], например, вроде смортится неплохо. С другой стороны - в чем неправильность этих тестбенчей, почему нет Оракловской супердупер дб-машины и нет МФ? Слишком дорого по удельной стоимости или другая причина неправильности?

[StrangerR]

Производительность заданого компьютера величина постоянная и неизменная. Время выпонения всего теста уменьшили бы несомненно. Ведь есть же еще запас в 33%-22%. Только не надо делать круглые глаза и говорить что при 100% загрузки все остановится.

именно этот запас и дает мне возможность оценить на сколько адекватна была настроена дисковая субсистема, совершенно не вникая в подробности конфига. 8 потоков МФ сумели "прокормить" процессоры грубо говоря на 70%. лично мне совершенно очевидно что даже 16 потоков если не в и/о упрется, то гарантированно упрется в процессоры МФ. далее наращивая кол-во потоков мы лишь увеличиваем конкуренцию за горячий ресурс и соответственно оверхед на обслуживание.
теперь смотрим на сантехнику - 32 потока лишь 44% на пике, т.е. запас по cpu почти двухкратный, в сравнении с МФ.

Я одно не понимаю. А на фига так насиловать дисковые системы то? На это все есть флеш кэш, есть умные ексадата дисковые стойки. Если МФ нужно вытягивать диски аж в 8 потоков, то наверное пора что-то менять в консерватории. Единственное приложение которому простительны такие потоки данных - это обработка видео.

[zVlad]

Чтобы перейти от пустопорожней болтовни и препирательств я послал запрос ИБМ (через службу поддержки ИБМ) с двумя вопросами по поводу "Oracle PeopleSoft Benchmark White Papers":

1. Участвовал ли ИБМ в этих тестах, и

2. Согласен ли ИБМ что в оракловских тестах на ИБМ МФ было сделано все чтобы показать на что способен ИБМ МФ в данном случае.

А пока, закончил я свой запрос, z10 EC 2097-709 выглядит хуже чем SUN SPARC M5000.

Буду держать вас в курсе этого диалога с ИБМ.

[StrangerR]

Влад.

А пошлите им запрос DB2 vs Oracle DB machine 2. Очень интересно, оракл что-то не мычит не телится с пресс релизами (а начиналось все очень пафосно,идея то отличная) - а ИБМ с удовольствием набросит говна на вентилятор и приведет примеры, если они есть... Вообще конечно качество Оракла стало ниже плинтуса, из за индусского аутсорсинга, так что шансы тут есть.

А выше вся дискуссия - не на тему _кто толще_. Если мне дадут много-много денег и задача будет подходящая, я с удовольствием поставлю два МФ на все про все. Дискуссия то на тему _результаты на $1_ - и тут у МФ ниш очень немного. Цена 1 гига памяти, к примеру, там выше в десятки раз.

[zVlad]

Влад.

А пошлите им запрос DB2 vs Oracle DB machine 2. Очень интересно, оракл что-то не мычит не телится с пресс релизами (а начиналось все очень пафосно,идея то отличная) - а ИБМ с удовольствием набросит говна на вентилятор и приведет примеры, если они есть... Вообще конечно качество Оракла стало ниже плинтуса, из за индусского аутсорсинга, так что шансы тут есть.

А выше вся дискуссия - не на тему _кто толще_. Если мне дадут много-много денег и задача будет подходящая, я с удовольствием поставлю два МФ на все про все. Дискуссия то на тему _результаты на $1_ - и тут у МФ ниш очень немного. Цена 1 гига памяти, к примеру, там выше в десятки раз.

Я еще не не читал, но вот что дает поиск на ИБМ сайте по теме Oracle DB machine 2:

ftp://ftp.software.ibm.com/linux/pdfs/C ... s-2010.pdf

[StrangerR]

Статья интересная в первой половине. А потом начинаются сплошные передергивания:
- Vmware 20 VM per CPU - нету там такого ограничения, даже на бесплатной ESXi.
- Сравнение Оракле vs IBM базируется на CPU. НО ведь ексадата то берет не CPU а тем что там умные дисковые стойки которые САМИ делают операции над таблицами базы данных - и в итоге если у вас 10 дисковых стоек то скажем полный скан таблицы делается параллельно на 10 серверах дисковой памяти. То есть идея оракла и ДБ машины - это
- модульность
- флеш память как память а не как диски (побочный эффект - оказалось что САС диски смысла не имеют никакого.)

Об этом не слова. Так что статья весьма и весьма однобокая. Хотя начало пожалуй абсолютно справедливо.

PS. Что касается VM - по жизни, кроме редких случаев, основной ограничитель их количества - оперативная память (процессоры почти всегда недогружены примерно в 4 - 10 раз). И эта вот память на МФ стоит на 1 гигабайт в десяток раз больше чем на интеле. Так что тут еще бабка надвое сказала, кто кого сборет по количеству VM на 1 килобакс вложений. Где ИБМ, вероятно, поборет интелловские ВМ облака - так это там где нужно выжать из ВМ производительность реальной железяки - дать ей 16 процессоров и пол терабайта памяти - такое VMware не может. То есть на интеле будет потребность перейти на реальную железку а на МФ все останется виртуальным. Но вот там где выжимать максимум не нужно - интел будет полным и безусловным победителем по расходу килобаксов на десяток ВМ-ок.

Я еще не не читал, но вот что дает поиск на ИБМ сайте по теме Oracle DB machine 2:

ftp://ftp.software.ibm.com/linux/pdfs/C ... s-2010.pdf

[zVlad]

Статья интересная в первой половине. А потом начинаются сплошные передергивания:
- Vmware 20 VM per CPU - нету там такого ограничения, даже на бесплатной ESXi.
......

PS. Что касается VM - по жизни, кроме редких случаев, основной ограничитель их количества - оперативная память (процессоры почти всегда недогружены примерно в 4 - 10 раз). И эта вот память на МФ стоит на 1 гигабайт в десяток раз больше чем на интеле. Так что тут еще бабка надвое сказала, кто кого сборет по количеству VM на 1 килобакс вложений. Где ИБМ, вероятно, поборет интелловские ВМ облака - так это там где нужно выжать из ВМ производительность реальной железяки - дать ей 16 процессоров и пол терабайта памяти - такое VMware не может. То есть на интеле будет потребность перейти на реальную железку а на МФ все останется виртуальным. Но вот там где выжимать максимум не нужно - интел будет полным и безусловным победителем по расходу килобаксов на десяток ВМ-ок.
.....

Вы очень странно рассуждаете о количестве ВМ. Ведь виртуальные машины это еще не нагрузка. Нагрузка это то что "сидит" в виртуальной машине. И это "то что" может загрузить реальную машину в количестве одна штука. Можно говорить о трех количествах ВМ. Теоретическом (у z/VM еще в 80-е этот параметр был десятки тысяч), реально активизированном, но когда ВМ ничего не делают, и реальном количестве с реальной загрузкой. Последняя величина будет очень разной для разных нагрузок.
Память тоже не параметр. У меня в 8 MB-ах под СВМ ЕС на ЕС 1061 десятки ВМ с реальной загрузкой выполнялись, которая представляла из себя смесь пакетной и диалоговой обработки.
Максимум на МФ выжимается не с z/VM. Вы похоже не как не можете понять что МФ и без z/VM может быть разделен на "виртуальные машины" называемые LPAR и их может быть до 32. А вот уже в LPAR может быть поставлена z/VM, которая соответственно породит виртуальные машины, и таких z/VM может быть до 32, или z/OS. В случае z/OS и без виртуализации можно выполнять такое количество разнообразных нагрузок каковое потянет реальная машина.
ваши параметры "количество VM на 1 килобакс" или "килобаксов на десяток ВМ-ок." не имеют под собой никакой реальности или потребительской ценности. Этими параметрами Вы лишь хотите сказать что известные Вам Wintel сервера (те с которыми Вы работаете) стоят дешевле известных Вам (по таблица цен в Интернете), в то время как с этим никто и не спорил никогда. Весь спор, на самом, вертится вокруг стоимости законченной инфраструктуры компаний больше чем несколькими сотнями работников (или больше чем чего-нибудь еще) со всеми расходами на инфраструктуру. Приобретение железа с этой точки зрения становится самой малой статьей расхода как в случае Wintel, так в случае МФ. А вот остальные статьи расхода очень разные получаются.