Акела промахнулся! В смысле, Интел обосрался

[zVlad]

Какие результаты Вы смотрели, от кого, про что, как Вы сравнивали, что, с чем.

http://www.oracle.com/us/solutions/benc ... 67486.html

Например эта пара:
http://www.oracle.com/us/solutions/benc ... 502957.pdf
http://www.oracle.com/us/solutions/benc ... 497509.pdf

Небольшой (!) мидрейнжевый сервер оказался почти в два раза быстрее, при этом загрузка ЦП была в два раза ниже (Он почти линейно масштабируется по процессору на разных задачах до упора. Их в хозяйстве было много.) Обычный честный batch.
....

В этом "обычном честном batch" в одном случае (z10) пускалось 8 job streams, а во втором (Sun T4) 96 job streams.

Обясните почему? Можно ли считать что выполнялся один и тот же тест в таком разе?

P.S. Это, кстати, лишь один из моментов наперстничества. Есть еще минимум два: диски и размеры RAM-ов. Сравните их тоже. Но главным остается первый: количество job streams.

[mskmel]

на мэйнфрэйм таких нагрузок не гоняют, не для этого берут мэйнфрэйм, не так грузят. Все не так. Количество заданий, помнится критиковал - с какой стати оно должно равняться количеству коров?

А какие гоняют? Вроде как по мне правоверная DB2.
Нашёл у нас Z10, работал(ет) под MQ чисто. Доступа туда естественно у меня нет и не будет

В этом "обычном честном batch" в одном случае (z10) пускалось 8 job streams, а во втором (Sun T4) 96 job streams.

Меня это тоже удивило. Видимо следущий шаг это 16, а загрузка уже была 70%+. Почему люди массово боятся 100% CPU usage мне так и не ясно за 20+ лет работы.
На Т4 потоки еще остались, зачем вообще Т4-4 было брать, если есть меньшие модельки.

[Flash-04]

Ну вообще-то система становится задумчивой при 100% нагрузке.

[zVlad]

Ну вообще-то система становится задумчивой при 100% нагрузке.

Обычные системы да, становятся задумчивыми. Но не zOS. Я в пиковые часы при 100% busy прекрасно работаю и наши пользователи тоже.

[alex_127]

Меня это тоже удивило. Видимо следущий шаг это 16, а загрузка уже была 70%+. Почему люди массово боятся 100% CPU usage мне так и не ясно за 20+ лет работы.

Потому что загрузка 60% не означает что кран открыт и их него течет 60% пропускной способности. Например это значит что в течении 600 миллисек в последней сек загрузка была 100%. Или 6 процессоров из 10 были заняты 100%. Кроме этого есть много тонкостей - длина квантума, ИО буст... Поэтому зависимость между загрузкой и например временем ответа нелинейна.

[zVlad]

....

В этом "обычном честном batch" в одном случае (z10) пускалось 8 job streams, а во втором (Sun T4) 96 job streams.

Меня это тоже удивило. Видимо следущий шаг это 16, а загрузка уже была 70%+....

То что загрузка "уже" была 70% ровным счетом ни о чем не говорит. Отдача МФ может расти и после того как достигнута загрузка CPU 100%. Вопрос лишь в том что мы будем понимать под "отдача".

Мой поинт прост. Мэйнфрэйм не был даже загружен на 100%, что означет что и МФ с меньшими возможностями мог бы работу теста выполнить с задаными ожиданиями. Вообще для пакетных заданий нормальные ожидания это: когда выполнится тогда и ладно. Что можно тестировать и увидеть гоняя абстрактые задания с не установленными показателями качества выполнения (обычно с заданиями связымваю пропускную способность) я понимать отказываюсь. Поэтому в общем и целом все такие тесты - это спекуляции на кофейной гуще.

На других платформах боятся 100% ЦПУ потому что система может прекратить выдавать любую работу, "сдуться" может, уйти "в нуль". Причем может уйти в нуль и с невысокой загрузкой CPU, а, например, из-за размера RAM.

[mskmel]

Поэтому зависимость между загрузкой и например временем ответа нелинейна.

№1
Вырожденный вариант - CPU bound process, 1 процессор.
Есть SLA: время отклика (ВО) 1сек,
Экспериментально установлено, что при 1-99% загрузки CPU имеем ВО < 0.1сек.
Каким образом 100% будет проблемой? Почему мониторим CPU, а не ВО? или run queue?

№2
Лет 10+ назад работал на одного достаточно жадного оператора связи, с постргессом и ораклом на биллинге. Серверы тарификации были в 100% 1-2 недели в месяц, остальное время отдыхали. Но пока они делали работу, которую они должны сделать никого это особо не беспокоило. Никому не надо было выставлять месячные счета за 1 час, за 2 недели вполне нормально. Запас в 2 раза это отлично. Даже поговаривали убрать парочку, чтобы уменьшить стоимость лицензий.

№3
Более сложный для понимания. Дано сервер х86 с 4мя или 8ю сокетами.
Средняя загрузка CPU 10%, но mpstat показывает что NumeNode0 Core0 = 100% всё время, и сервер в одной подсети имеет pings 100msec. После исследования выясняется, что оно занято IRQ сетевых карт. Как поможет знание что Total CPU usage всего 10%?

Очевидно что еще можно придумать сценарии, но направление мысли понятно. 100% CPU usage != у нас проблемы. Также как и с памятью кстати.

[mskmel]

Мэйнфрэйм не был даже загружен на 100%, что означет что и МФ с меньшими возможностями мог бы работу теста выполнить с задаными ожиданиями.

Стоимостью в 20 раз ниже? Не уверен.

[Dmitry67]

Отдача МФ может расти и после того как достигнута загрузка CPU 100%.

Именно, до 146% CPU

[mskmel]

Ну вообще-то система становится задумчивой при 100% нагрузке.

Экспериментальным путём установлено, что юзеры нихрена не замечают пока загрузка не станет 200% Т.е. грубо говоря два CPU bound процесса на ядро.

В Z, судя по всему, процессоры очень быстрые на один поток, так что всё должно быть ОК при 100% нагрузке. При их стоимости иметь 70% это выкидывать несколько сотен тыщ или даже миллионы $ в год.

[zVlad]

Отдача МФ может расти и после того как достигнута загрузка CPU 100%.

Именно, до 146% CPU

Загрузки больше 100% не бывает, Дима. Речь одет о том что кроме CPU на сервере есть два, если грубо, других ресурса: память и ввод-вывод. Речь идет о том что при 100% CPU busy отдача может расти за счет "дозагрузки" ввода-вывода и памяти.

[zVlad]

Мэйнфрэйм не был даже загружен на 100%, что означет что и МФ с меньшими возможностями мог бы работу теста выполнить с задаными ожиданиями.

Стоимостью в 20 раз ниже? Не уверен.

Ну вообще-то система становится задумчивой при 100% нагрузке.

Экспериментальным путём установлено, что юзеры нихрена не замечают пока загрузка не станет 200% Т.е. грубо говоря два CPU bound процесса на ядро.

В Z, судя по всему, процессоры очень быстрые на один поток, так что всё должно быть ОК при 100% нагрузке. При их стоимости иметь 70% это выкидывать несколько сотен тыщ или даже миллионы $ в год.

Я не думаю что Вы так просты что можете считать что "стоимости" в данном случае это всего лишь прейскурантные цены железяк. Наверняка если начать с Вами говорить по-серьезному Вы согласитесь что и другие взгляды на стоимости ИТ кроме Total Cast of Acquisition (TCA), например, считают и Total Cost of Ownership (TCO). Есчце я могу добавить для раздумия что такие продукты как Oracle калькулируются по количеству коров на сервере. Так вот давно известно что коров МФ для одной и той же нагрузки s Oracle может быть нужно в, скажем, 20 раз меньше.
Весной прошлого года я обедам с двумя ИБМ-цами в Москве. Один из них занимается темой TCO, и вот он говорил мне "как не считай, но TCO MF всегда лучше любых других вариантов получается.

[Dmitry67]

Отдача МФ может расти и после того как достигнута загрузка CPU 100%.

Именно, до 146% CPU

Загрузки больше 100% не бывает, Дима. Речь одет о том что кроме CPU на сервере есть два, если грубо, других ресурса: память и ввод-вывод. Речь идет о том что при 100% CPU busy отдача может расти за счет "дозагрузки" ввода-вывода и памяти.

.... как и на любом другом процессоре.
Например, суммирование всех элементов большой матрицы по I,J и по J,I дают один и тот же результат и нагружают проц до 100%, так как задача чисто рассчетная, но один из алгоритмов cache friendly и работает примерно раз в 20!!! быстрее

[zVlad]

....

В Z, судя по всему, процессоры очень быстрые на один поток, так что всё должно быть ОК при 100% нагрузке. При их стоимости иметь 70% это выкидывать несколько сотен тыщ или даже миллионы $ в год.

Не потому вовсе все ОК что "Z, судя по всему, процессоры очень быстрые на один поток" (я вообще не понял что Вы хотели сказать сделав оговорку про "один поток"). "Z процессоры" могут быть одинаково быстрыми в разном наборе их количества. Например модель zBC12-A06 (шесть CPU, 233 MIPS) так же быстро как и модель zBC12-M01 (один CPU, 242 MIPS).

Там все ОК благодаря zOS и его WLM -- Workload Manager. Если Вы хотите "дешевый" МФ (есть и такие), то Вам придется на него ставить Linux. И все сразу будет примерно как на любых других серверах, не-МФ.

[zVlad]

Отдача МФ может расти и после того как достигнута загрузка CPU 100%.

Именно, до 146% CPU

Загрузки больше 100% не бывает, Дима. Речь одет о том что кроме CPU на сервере есть два, если грубо, других ресурса: память и ввод-вывод. Речь идет о том что при 100% CPU busy отдача может расти за счет "дозагрузки" ввода-вывода и памяти.

.... как и на любом другом процессоре.
Например, суммирование всех элементов большой матрицы по I,J и по J,I дают один и тот же результат и нагружают проц до 100%, так как задача чисто рассчетная, но один из алгоритмов cache friendly и работает примерно раз в 20!!! быстрее

Дима, прочти, пожалуйста, то мое к чему ты написал свое и подумай.