IBM PC

User avatar
flip_flop
Уже с Приветом
Posts: 4379
Joined: 20 Jun 2001 09:01

Re: IBM PC

Post by flip_flop »

mskmel wrote:
flip_flop wrote:
mskmel wrote:пусть они в 5 раз быстрее x86
С какого перепуга? Есть легко определяемая теоретическая производительность чипа, измеряемая в терафлопах. Например, мой старый чип, выпущенный 3 года назад, имел примерно 1 терафлоп для чисел двойной разрядности. Для МФ таких данных нет, поскольку "числа не адекватны" :D
Не совсем так. Флопы - флопами, но реализованные в железе специфичные SW функции могут сильно изменить конечную картинку специализированного приложения. Куча переменных в виде "помещается ли в кэше процессора", "требовательна ли к латентности памяти" и т.д. и т.п.

Плюс производительность всей системы это не только производительность чипа.
Ну пусть не только флопы. Дайте другие показатели, числа, результаты тестов, в конце концов. Для МФ же "числа не адекватны" и их почти нет. А мои числа относились только к CPU, потому как адресовались на вашу ремарку именно о чипах, см вверху в цитате :D
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:
flip_flop wrote:
mskmel wrote:пусть они в 5 раз быстрее x86
С какого перепуга? Есть легко определяемая теоретическая производительность чипа, измеряемая в терафлопах. Например, мой старый чип, выпущенный 3 года назад, имел примерно 1 терафлоп для чисел двойной разрядности. Для МФ таких данных нет, поскольку "числа не адекватны" :D
Не совсем так. Флопы - флопами, но реализованные в железе специфичные SW функции могут сильно изменить конечную картинку специализированного приложения. Куча переменных в виде "помещается ли в кэше процессора", "требовательна ли к латентности памяти" и т.д. и т.п.

Плюс производительность всей системы это не только производительность чипа.

Золотые слова. Наконец то появился человек с которым можно о чем то говорить. Вы, mskmel, практически дошли до понимания разницы между МФ и северами на Intel.
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: IBM PC

Post by mskmel »

zVlad wrote:Золотые слова. Наконец то появился человек с которым можно о чем то говорить. Вы, mskmel, практически дошли до понимания разницы между МФ и северами на Intel.
Чисто производительность мало кого интересует, интересует соотношение цены к производительности. Упорное умалчивание IBM-ом обоих параметров и почти полное отсутствие МФ на рынке private cloud наводит на мысли, что всё не так уж хорошо.

Заявление IBM о 8000VMs это blatant bullshit, по чуть больше 1ГБ на виртуалку это смешно :)
2.5ярда транзакций в день тоже смешно, 3 года назад SPARC T5-8 показал 8.5млн\минуту в TPC-C, это 12ярдов в день. IBM посрамлён :) С разницей что в SPARC понятно какие транзакции мерял, а в z13 сам IBM что-то где-то мерял.

Много лет назад (2005?), мне довелось понаблюдать работу Oracle на z-Series, на который было наставлено много много всего, потому что таков корп стандарт, так привыкли. БД катастрофически не хватало памяти, против лома - нет приёма, базе нужен нормальный кэш, не одна архитектура не исправит на порядки более дорогого доступа к данным лежащим на СХД. На предложение выделить хотя бы 128ГБ, по тем временам ерунда полная, админы широко раскрыли глаза, и возвопили что столько памяти никогда никому не давали, и что вообще её там не сильно то и больше чем 128ГБ, а еще надо кучу всего гонять :cry:
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:...Заявление IBM о 8000VMs это blatant bullshit, по чуть больше 1ГБ на виртуалку это смешно :)
...
Я уверен, вы слышали про виртульную память.
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:...2.5ярда транзакций в день тоже смешно, 3 года назад SPARC T5-8 показал 8.5млн\минуту в TPC-C, это 12ярдов в день. IBM посрамлён :) С разницей что в SPARC понятно какие транзакции мерял, а в z13 сам IBM что-то где-то мерял.
...
Я не люблю таких заявлений и пропускаю их мимо ушей. Это маркетинговые штучки и нам, спецам, не стоит на них зацикливаться. Но я знаю МФ с другой стороны, со стороны практического их использования, и я вижу как ломаются стереотипы рожденные на других платформах.
Например, в начале этого года мы перевели на МФ 2000+ пользователей из-под SAP. Со всеми их данными и функциональностью. SAP их стоял на некоторым количестве серверов с Oracle БД тоже на нескольких серверах. Все это пришло на достаточно загруженный МФ (я имею в виду тот о котором только что писал) без добавление единого байта и герца, не говоря уже об ядрах.
Ранее я эспериментировал с WebSphere на том же МФ. Без zIIP это действительно было тоскливо, хотя и не мешало ничему. А вот с zIIP (одна штука) это просто летало. Сейчас та часть что на WebSphere должна была быть сидит на некотором количестве AIX сервер-ов, с гораздо большим количеством GB чем у меня было в нашей Development (тоже писал выше), а было там всего 8 GB на все про все, не только WebSphere.
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: IBM PC

Post by mskmel »

zVlad wrote: Например, в начале этого года мы перевели на МФ 2000+ пользователей из-под SAP.
2000 юзеров-людей это 8 ядрышек х86 образца 10 лет назад.

Оракл на МФ видел своими собственными глазами, это "цик с гвоздями". Дело как уже писал было совсем не в процессорах. Про виртуальную память слышал, это здорово, но какой смысл свопить на диск память, которая предназначена для кэширования данных с диска?
zVlad wrote:Ранее я эспериментировал с WebSphere на том же МФ...8 GB
Если это летает, то почему нет specjbb результатов?
8ГБ - для stateful приложений с большим количеством "живых" сессий это не о чем.

Вы не ответили на вопрос о цене z13 для 200х 50ГБ виртуалок для вебсферы :)
User avatar
flip_flop
Уже с Приветом
Posts: 4379
Joined: 20 Jun 2001 09:01

Re: IBM PC

Post by flip_flop »

zVlad wrote:
mskmel wrote:
flip_flop wrote:
mskmel wrote:пусть они в 5 раз быстрее x86
С какого перепуга? Есть легко определяемая теоретическая производительность чипа, измеряемая в терафлопах. Например, мой старый чип, выпущенный 3 года назад, имел примерно 1 терафлоп для чисел двойной разрядности. Для МФ таких данных нет, поскольку "числа не адекватны" :D
Не совсем так. Флопы - флопами, но реализованные в железе специфичные SW функции могут сильно изменить конечную картинку специализированного приложения. Куча переменных в виде "помещается ли в кэше процессора", "требовательна ли к латентности памяти" и т.д. и т.п.

Плюс производительность всей системы это не только производительность чипа.

Золотые слова. Наконец то появился человек с которым можно о чем то говорить. Вы, mskmel, практически дошли до понимания разницы между МФ и северами на Intel.
Хе-хе, толстый намёк на то, что со всеми остальными на этом форуме нельзя говорить вообще ни о чём, напрочь :D Будто бы кто-то спорит с необходимостью анализа целостной системы.

Вторая ваша сентенция вообще интересна, типа МФ - красивая система, серверы на Интел - сборище чипов. Профанация, одним словом.
User avatar
flip_flop
Уже с Приветом
Posts: 4379
Joined: 20 Jun 2001 09:01

Re: IBM PC

Post by flip_flop »

mskmel wrote: Если это летает, то почему нет specjbb результатов?
Золотые слова. Наконец то появился человек, с которым можно поговорить. Почти дошедший до понимания между МФ и серверами на Интел.
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:
zVlad wrote: Например, в начале этого года мы перевели на МФ 2000+ пользователей из-под SAP.
2000 юзеров-людей это 8 ядрышек х86 образца 10 лет назад.

Оракл на МФ видел своими собственными глазами, это "цик с гвоздями". Дело как уже писал было совсем не в процессорах. Про виртуальную память слышал, это здорово, но какой смысл свопить на диск память, которая предназначена для кэширования данных с диска?
zVlad wrote:Ранее я эспериментировал с WebSphere на том же МФ...8 GB
Если это летает, то почему нет specjbb результатов?
8ГБ - для stateful приложений с большим количеством "живых" сессий это не о чем.

Вы не ответили на вопрос о цене z13 для 200х 50ГБ виртуалок для вебсферы :)

То что Oracle на МФ это "цик с гвозьдями" для меня не сюрприз. Кэширование данных с диска тоже может быть сделано по разному и требовать разные размеры в зависимости от частоты обращения к этим данным. Это не тривиальная тема, но в двух словах если данные считываются лишь для того чтoбы узнать что они не нужны, то никакого кэша для них отводить не надо. Современные дисковые подсистемы имеют свои и порой весьма большие кэши. Вот о них и следовало бы спрашивать.
В DB2 на МФ данные считываются в буфер (их может быть больше одного конечно). Естественно ограниченного размера. Если памяти в буфере нет то DB2 сама решает что оттуда можно выбросить и как чтобы считать новую порцию данных. DB2 буфера могут быть зафиксированны в реальной памяти или свопаться. Об этом можно долго говорить.

Я на вопросы о ценах на МФ не отвечаю никогда. Я не торгую МФ-мами тем болеe для неизвестно чего. Я могу проконсультировать по поводу какого размера МФ следует брать, но для того чтобы это сделать мне понадобится определенные данные. Плюс, не надо забывать что решения принятые на одной платформе (200 VMs с WebSphere), не обязательно будут еффективны на другой (может быть для цели достаточно будет одного WebSphere под zOS, я не знаю, и Вы тем более) и это может существенно поменят другие параметры влияющие на цены. Если работать серьезно, то начинать нужно не с того с чего Вы начали, а гораздо раньше. Вы мне даете требования из решения на Интел и спрашиваете про МФ. А надо сначалa, исходя из бизнес требований, сделать проект на МФ, и только потом решать какой МФ нужно будет купить под этот проект. Так же и если решается обратная задача. Мы же пойдем с МФ на Интел не с теми же цифрами что имеется на МФ, не с 5 CPU и 24 GB памяти. За перенос нашего приложения на Интел сервер с 5 CPU и 24 GB памяти того что сейчас выполняется на нашем МФ IT менеджера расстреляют три раза как минимум, потому что это будет дизастер. На каком количестве серверов Интел обединенных в кластер начнется норамльная работа Production можно лишь догадываться.
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: IBM PC

Post by mskmel »

flip_flop wrote:
mskmel wrote: Если это летает, то почему нет specjbb результатов?
Золотые слова. Наконец то появился человек, с которым можно поговорить. Почти дошедший до понимания между МФ и серверами на Интел.
Я, в силу любознательности, хочу понять на сколько это круто и сколько за это круто хотят денег. Окружающая действительность говорит о том, что люди, советующие тратить деньги, как и люди, выделяющие деньги, даже не смотрят в сторону оптимизации стоек с VM на ESX до одного МФ. Одно из двух, это или не так круто как заявляет IBM или в IBM продавцы работать не могут.

Под БД использовать МФ смысла не вижу совсем, очень дешево работает KIWI на х86 (Kill It With Iron). Для БД важно сколько памяти и на сколько быстра СХД. Для МФ память дорогая, СХД от МФ не зависит совсем.
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: IBM PC

Post by mskmel »

zVlad wrote:Современные дисковые подсистемы имеют свои и порой весьма большие кэши. Вот о них и следовало бы спрашивать.
Кэш СХД слишком далеко от процессора (латентность) и его слишком мало, за него большая конкуренция от других потребителеq... Так что это мимо, от слова совсем.
К сожалению IBM не публикует SAP бенчмарков DB2 for Z\OS, тогда можно было бы сравнивать.

Также как и не публикует specjbb чтобы интеполировать текущие системы на МФ.

Edit: Нашел https://www-03.ibm.com/support/techdocs ... e_V1.2.pdf" onclick="window.open(this.href);return false;

Забавное чтиво :)
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:
zVlad wrote:Современные дисковые подсистемы имеют свои и порой весьма большие кэши. Вот о них и следовало бы спрашивать.
Кэш СХД слишком далеко от процессора (латентность) и его слишком мало, за него большая конкуренция от других потребителеq... Так что это мимо, от слова совсем.
К сожалению IBM не публикует SAP бенчмарков DB2 for Z\OS, тогда можно было бы сравнивать.

......
СХД - это что? харддрайв? а С тогда что?

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

А вот Ваши сервера "висят" на одной веревке и имеют латенси и как бы всерьез не рассматриваются. Это понятно, но это иначе в случае МФ и вполне может рассматриваться.
сумарно буфера нашей продакшн DB2 больше чем доступная реальная память. Но страничного обмена нет. И лишь иногда для каких то уникальных запросов страничный обмен появляется и даже значительный. Но это редко бывает и ни на что не влияет.
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:
flip_flop wrote:
mskmel wrote: Если это летает, то почему нет specjbb результатов?
Золотые слова. Наконец то появился человек, с которым можно поговорить. Почти дошедший до понимания между МФ и серверами на Интел.
Я, в силу любознательности, хочу понять на сколько это круто и сколько за это круто хотят денег. Окружающая действительность говорит о том, что люди, советующие тратить деньги, как и люди, выделяющие деньги, даже не смотрят в сторону оптимизации стоек с VM на ESX до одного МФ. Одно из двух, это или не так круто как заявляет IBM или в IBM продавцы работать не могут.

Под БД использовать МФ смысла не вижу совсем, очень дешево работает KIWI на х86 (Kill It With Iron). Для БД важно сколько памяти и на сколько быстра СХД. Для МФ память дорогая, СХД от МФ не зависит совсем.
Есть несколько причин почему они не смотрят в сторону МФ. Во первых, в силу того что МФ уже давно не преподаются в университетах об них мало кто знает что-нибудь кроме баек рассказываемых ихними старшими коллегами когда то в молодости обожглись на МФ (таких навалом здесь на форуме). Во-вторых, это проще купить столько дешевого харда сколько можно продать с прибылью через рент, как бы виртуальных, ресурсов. Иными словами купить блэйды оптом по три копейке и сдавать их за три копейки в месяц. Тоже можно и на Мф достичь, только купить надо не мешок блэйдов, а один сервер и знать как на одном сервере выполнять тысячи копеечных ресурсов окупая затраты.
Если не читали про zEnterprise - это гетерогенная архитектура в которой блэйды и МФ работают вместе. это путь сделать МФ, и так экономически обоснованный, еще более выгодным.
Кстати обратное тоже имеет место быть : те кто имеет МФ не торопятся с них уходить и даже возвращаются уйдя ранее. Теперь такие уже никуда с МФ не уйдут.
В нашей фирме с 1995 года уходят с МФ. Последние годы я каждый месяц слышу о том что мы последнее приложение переведем с МФ. И вот к концу этого года мы переходим на новые МФ и берутся эти новые МФ сроком на пять лет минимум. Это zBC12, не z13 (z13 ВС еще не продаются и не аннонсированы, а ЕС для нас слишком велики). А в связи с тем что все остальное снесено было с МФ у нас складывается уродская ситуация когда мы будем иметь два МФ и один из них будет стоять без работы - как дизастер рековери сайт. Это полный бред, и до этого бреда мы доходим из-за дремучего невежества и неумения планировать структуры нашего ИТ. И еще радуются что раз на одном МФ не будет софта, то и за софт то платить не надо будет. Уря. Это продукт ментальности распределенных структур. Даже то что стоят без дела будет железа на поллимона никого не волнует. Может этого и не будет, это только черновой проект, но пока об этом говорят.
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:....

Также как и не публикует specjbb чтобы интеполировать текущие системы на МФ.

Edit: Нашел https://www-03.ibm.com/support/techdocs ... e_V1.2.pdf" onclick="window.open(this.href);return false;

Забавное чтиво :)
Я имею опыт когда люди читая такие источники получают весьма неадекватные впечатления. Прошу Вас делиться впечатлениями, может Вам надо будет помочь разобраться. Я готов. Сам тоже почитаю, завтра.
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: IBM PC

Post by mskmel »

zVlad wrote:СХД - это что? харддрайв? а С тогда что?
Система Хранения Данных
zVlad wrote:Наши, весьма скромные МФ, каждый имеет выделенные каналы (физические линии/оптоволокно) к дисковой системе. И их не один, а в нашем случае аж четыре (в старших моделях их сотни).

Code: Select all

lsdev -Cc adapter | grep -c  "Fibre Channel"
30
zVlad wrote: А вот Ваши сервера "висят" на одной веревке и имеют латенси и как бы всерьез не рассматриваются.
У Вас весьма неверные представления о параллельном мире. На одну верёвку никто (кроме пионеров) никогда ничего не вешал. Минимум 2, как правило 4-8, в особо извращенных ситуациях сильно больше. Это называется multipathing.

Латентность самих интерфейсов ничтожно мала относительно латентности "дисков".
Латентность памяти ничтожно мала даже относительно латентности интерфейсов.
Кэширование в локальной памяти всегда на порядки быстрее самых быстрых "дисков" - ms vs ns

Так же относительно давно пришли:
* CNA (converged network adapter)
* SDN (Software Defined Networking)
* SDS (Software Defined Storage) это сейчас в тренде
zVlad wrote:Это zBC12
...
Даже то что стоят без дела будет железа на поллимона никого не волнует
Пол ляма, за начальную железку прошлого поколения всего с макс 500ГБ рамы и аж 13ю ядрышками?!

Точно параллельная реальность...
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: IBM PC

Post by mskmel »

zVlad wrote: В нашей фирме с 1995 года уходят с МФ. Последние годы я каждый месяц слышу о том что мы последнее приложение переведем с МФ.
Миграция с платформы на платформу это технически осуществимая задача при наличии мотивированного менеджмента и бюджета. В вашем конкретном случае, явно дешевле заплатить 1млн за новые железки и продолжать платить текущим специалистам. Как только столкнутся с необходимостью "покупать" следующее поколение специалистов возможно станет больше мотивации.


4.0
all test scenarios were done using a physical 3-tier environment where each of the three layers resided on separate machines
4.1 Hardware
A few measurements were done with a z10 model 2097-E26 with 14 cps configured online
цена где-то от 1млн
http://www.tech-news.com/publib/pl2097.html" onclick="window.open(this.href);return false;
5.5
The details of these runs using the SAP SD workload
# of CPs 14
# of Users 19,200
%CPU on z/OS 70.34%
Идём SAP SD Standard Application Benchmark Results, Three-Tier Internet Configuration
http://global.sap.com/solutions/benchma ... px?num=200" onclick="window.open(this.href);return false;

Ближайший результат на DB2, пусть и предыдущей версии, ещё и UDB
IBM System p 550, 2 Processors / 4 Cores / 8 Threads, POWER6, 4.2 Ghz
# of Users 32000

Всего 4ре ядра на 3 года раньше показали заметно лучший результат.
Каких бы чудес не происходило внутри МФ, но используя в 3 раза меньше ядер получить на 30-40% лучший результат...

А если еще посчитать, сколько вообще можно было ядер за 1млн накупить, то становится понятной текущая ситуация с МФ. И это запиленный специально под МФ DB2, что говорить о прочем коде, который не писался с оглядкой на платформу?
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:...
Латентность самих интерфейсов ничтожно мала относительно латентности "дисков".
Латентность памяти ничтожно мала даже относительно латентности интерфейсов.
Кэширование в локальной памяти всегда на порядки быстрее самых быстрых "дисков" - ms vs ns

..
А кэш в дисковой подсистеме у Вас куда делся?

Хорошо что у вас, в параллельном мире, может быть 30 FiberChannels на один сервер. тогда откуда сетования на "большую конкуренцию от других потребителей". Какой смысл иметь 30 путей к дискам которые лишь в малой степени принадлежат данному серверу? Я сомневаюсь, кстати, что Вашей командой вернувшей число 30 Вы показали наличие 30-ти физических каналов доступа. Я посмотрю что такое multipathing конечно, но Вы тоже подумайте о чем речь. В наш МФ физически приходят 16 оптопроводов и каждый подключен к своему разъемы, которых по четыре на каждой из четырех Ficon Express4 карт. К Вашему серверу, если сравнивать апельсины с апельсинами, должно подходить 30 оптоволокнов. С другой стороны наши оптопровода подключены к разъемам адаптеров Ficon на СХД и кэш у этих адаптеров свой и довольно большой. Так называемые OpenSystem имеют свои входы в СХД и как они их делят между собой я не знаю.
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: IBM PC

Post by mskmel »

zVlad wrote: Хорошо что у вас, в параллельном мире, может быть 30 FiberChannels на один сервер. тогда откуда сетования на "большую конкуренцию от других потребителей". Какой смысл иметь 30 путей к дискам которые лишь в малой степени принадлежат данному серверу?
Один storage на один сервер уже лет 10-15 как не покупают. "Принадлежат данному серверу" полностью противоречит идее shared storage. Так же как и на обычных серверах мониторят загрузку "контроллеров", отдельные контроллеры выделяются под отдельные задачи, в случае если на них есть bottleneck. С распространением tiered storage идея одна задача - один storage вообще утопична.
Монолитные системы хранения данных отмерли почти так же как и монолитные МФ, исключение некоторые подвиды all-flash.
IBM в хранилках никогда особо сильной не была, потому лучше гуглить на EMC VMAX, EMC FAST VP и там дальше по ссылкам...
Иметь своим порты на массиве - не значит иметь свои личные диски, если мне не врёт память, года с 2002го у EMC управление на уровне кусочков диска "hypervolume", из них лепят metavolume и отдают серверам.
С появлением storage pools и tiering понять на каком типе дисков лежит кусок конкретного файла вообще затруднительно. Стоит признать работает вполне так нормально, если понимать физику процесса.

И это я еще SDS даже не коснулся :) Тут лучше начать отсюда http://www.vmware.com/products/virtual-san" onclick="window.open(this.href);return false; или http://www.emc.com/storage/scaleio/index.htm" onclick="window.open(this.href);return false; и дальше гуглить. Для больших тяжелых БД оно пока не нужно, но управлять полчищами VM\VDI якобы самое оно.
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:
zVlad wrote: Хорошо что у вас, в параллельном мире, может быть 30 FiberChannels на один сервер. тогда откуда сетования на "большую конкуренцию от других потребителей". Какой смысл иметь 30 путей к дискам которые лишь в малой степени принадлежат данному серверу?
Один storage на один сервер уже лет 10-15 как не покупают. "Принадлежат данному серверу" полностью противоречит идее shared storage. Так же как и на обычных серверах мониторят загрузку "контроллеров", отдельные контроллеры выделяются под отдельные задачи, в случае если на них есть bottleneck. С распространением tiered storage идея одна задача - один storage вообще утопична.
Монолитные системы хранения данных отмерли почти так же как и монолитные МФ, исключение некоторые подвиды all-flash.
IBM в хранилках никогда особо сильной не была, потому лучше гуглить на EMC VMAX, EMC FAST VP и там оно.
Я разбирал Вашу находку в тесте на SAP. писал текст, но Chrome на моем iPad сглючил и текст пропал. Я даю Вам до завтра время чтобы понять что Вы так поняли (преднамерено или нет я не знаю) и исправить Ваши выводы. Если Вы сами этого не сделаете я сделаю это за Вас. теперрь поговорим о дисках.
Никто не говорил одна задача - одна сторедж. Говорилось один сервер - одна сторедж. А в случае МФ правильнее будет один Sysplex -одна сторадж. Sysplex это Oracle RAC только лучше, и это когда несколько МФ имеют доступ к одним и тем же данным на дисках с целью их совместного использования. Почуствуйте разницу. У Вас, на ваших серверах, используют shared storage разделенную между серверами, но все равно через тот или иной bottleneck. Разделяют просто потому что при размерах современных дисковых систем ХД только много серверов могу сделать экономичным приобретение таких больших СХД. Плюс спасает тот факт что вся совокупность серверов на одной сторедж не сосет данные с высоким рейтом постоянно, а делают это в более менее короткие отрезки времени, импульсивно, и не все сразу. Расчет только на это.
не знаю что такое монолитные СХД. SSD знаю. Вам наверное просто хотелось сказать про монолитность Мф, которой на самом деле нет уже гораздо больше чем 10-15 лет, но хранилки ИБМ ничем не хуже, а может быть и лучше чем у перечисленных других. У нас используют ЕМС, почему спросите, потому что дешевле, больше не почему. НР у нас были до ЕМС, НР были еще дешевле, но глюкавее. А до НР были и ИБМ, но это было давно.
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:.....
Иметь своим порты на массиве - не значит иметь свои личные диски, если мне не врёт память, года с 2002го у EMC управление на уровне кусочков диска "hypervolume", из них лепят metavolume и отдают серверам.
С появлением storage pools и tiering понять на каком типе дисков лежит кусок конкретного файла вообще затруднительно. Стоит признать работает вполне так нормально, если понимать физику процесса.
....
Нет не значит. Но если посмотреть архитектуру внутреннего устройства дисков ЕМС и архитектуру дисков МФ то можно понять что в случае МФ есть вполне определенный мапинг одних в другие. Прежде чем я смогу сконфигурировать диски для zOS на ЕМС делается некая конфигурация результатом которой является однозначное определение местоположения дисков zOS на дисках в ЕМС. Все диски внутри ЕМС доступны всем серверам в ЕМС, это так, но... чтобы не лезть глубоко в детали можно так сказать про ЕМС и МФ с одной стороны и ЕМС и остальные сервера с другой. Начнем с других. Для них ЕМС подобен NFS. Все понятно. Для МФ ЕМС эмулирует все фичи ИБМ 3390 дисков и все фичи Ficon. Чтобы это было возможным ЕМС должно знать все про 3390 сконфигурированные на МФ и все фичи которые может затребовать ОS МФ. Некоторые фичи платные при этом и опшионал. Опять же долго рассказывать, да и далек я от проблем сторедж хотя и знаю кое-что поскольку на МФ конфигурую все это сам по согласованию с дисковиками.
iDesperado
Уже с Приветом
Posts: 1349
Joined: 28 Nov 2008 17:50

Re: IBM PC

Post by iDesperado »

Sysplex это динозавр из 60х, от которого по хорошему нужно было бы в 70х избавляться. это железячка с процессором и памятью соединяющая мейнфреймы, там сидит кеш db2. db2, который не нашел данных в памяти, лезет в общий кеш db2 на sysplex. если данные изменила один мейнфрейм, то он начинает гнать их в общий кеш на sysplex. подозреваю проектировал такую хрень наркоман, наверно по этому кластеры на МФ так и не прижились.
RAC же полная противоположность. это софт, а не железячка. у RAC нет единого кеша, как у sysplex. у RAC все ноды, если не нашли данные у себя, берут данные не в едином кеше, а у одной из нод кластера.

zVlad, вы снова забываете принимать таблетки от склероза. примите, мы уже с вами обсуждали и что такое схд, как связываются с компьютерами и сколько их на систему можно повесить. на примерах tpc.org обсуждали.
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:...

4.0
all test scenarios were done using a physical 3-tier environment where each of the three layers resided on separate machines
4.1 Hardware
A few measurements were done with a z10 model 2097-E26 with 14 cps configured online
цена где-то от 1млн
http://www.tech-news.com/publib/pl2097.html" onclick="window.open(this.href);return false;
5.5
The details of these runs using the SAP SD workload
# of CPs 14
# of Users 19,200
%CPU on z/OS 70.34%
Идём SAP SD Standard Application Benchmark Results, Three-Tier Internet Configuration
http://global.sap.com/solutions/benchma ... px?num=200" onclick="window.open(this.href);return false;

Ближайший результат на DB2, пусть и предыдущей версии, ещё и UDB
IBM System p 550, 2 Processors / 4 Cores / 8 Threads, POWER6, 4.2 Ghz
# of Users 32000

Всего 4ре ядра на 3 года раньше показали заметно лучший результат.
Каких бы чудес не происходило внутри МФ, но используя в 3 раза меньше ядер получить на 30-40% лучший результат...

А если еще посчитать, сколько вообще можно было ядер за 1млн накупить, то становится понятной текущая ситуация с МФ. И это запиленный специально под МФ DB2, что говорить о прочем коде, который не писался с оглядкой на платформу?
Второй день от Вас нет реакции на мой намек о некорекности Ваших выводов из найденных Вами данных двух тестов.
Мне ничего не остается как поправить Вас.

Прежде ремарка: цена за 14 CPU mainframe будет существенно больше 1 миллиона.

Вы увидели только количество юзеров. Между тем в докементе о тесте на МФ говорится:
We ran 19,200 SD users on a z10 14w with DB2 10 and 841 concurrent threads using three different values for MAXKEEPD, 0K, 8K, and 64K.
Из чего следует что 19200 были выбраны не с цел/ю показать как много юзеров может потянуть МФ с 14 CPU, а с целю показать как MAXKEEPD влияет на результат.

Далее. Результат приведенный Вами показывает один столбец из таблицы с тремя столбцами, для трех тестов:
DB2 level DB2 10
MAXKEEPD 0K 8K 64K
Run id S00730F1 S00719F2 S00719F1
# of CPs 14 14 14
# of Users 19,200 19,200 19,200
# of DB2 Threads 841 841 841
MAXKEEPD 0K 8K 64K
%CPU on z/OS 92.76% 84.79% 70.34%
ETR (DS/sec) 1,671.91 1,796.14 1,852.19
ITR (DS/sec) 1,802.40 2,118.34 2,633.20
Response Time (secs) 1.492 0.696 0.373
Virtual Storage Used
DBM1 Below 2GB 94.62 MB 93.39 MB 92.53 MB
Local Statement Cache Hit Ratio 0 46% 100%
Table 10: Measurement Data - Varying MAXKEEPD with DB2 10 and SAP SD
По какому принципу Вы выбрали третий столбец я не знаю, но давайте сравним и другие данные этого столбца с данными из тест на SAP проводимого с целью показать максимум количества юзеров (32 000).
%CPU: MF - 70.34%, Power - 99% (CPU MF явно не догружен и мы далеки (на сколько не знаю) от максимума по юзерам).
Response time: MF - 0.373 sec Power - 1.89 sec (У Мф результат лучше в почти 20 раз).
Memory: MF - 26 GB Power - 64 GB
Количество DB2 threads на Мф было ограничено до 841. В документ есть данные теста с 2,500 DB2 threads.
Данных о дисках для Power не приводится. Про диски для z10 говорится:
Two SD databases were used in these measurements. ...
The databases reside on a Model 800 (2105-800) with a total of eight FICON Express8 attachments to the
System z processor. The 2105-800 is a Turbo model with twenty-four 8-packs of 10K RPM 36.4GB
drives each. The actual capacity was five hundred twelve 3390-9 volumes, a total of about 4.6 TB. The
Model 800 had 16 GB regular cache and 2 GB non-volatile storage (NVS) and used RAID 5 (Redundant
Array of Independent Disks). Roughly half of the volumes were used for the databases and DB2
subsystems. The SD workload has minimal database I/O so using older DASD is adequate for the I/O
load. The FICON Express8 attachments had an effective rate of only 4 Gbps due to older/slower host
adapters on the DASD and switch.
Вы подчеркнули что данные тест на Power system даны были на 3 года раньше чем тест на МФ. Но z10, используемый в выбранном Вами тесте, это не МФ 2011-го года, а МФ 2008-го года.

Я уж не говорю о том что мы не знаем из документа по тестам на МФ какая модел была использована в тесте для 14 CPU, мы только знаем что это была E26, что лишь говорит о максимуме CPU в ней - 26, но не говорить об уровне мощности (capacity model), которых у каждой конфигурации МФ может быть до 26. Т.е. масштаб возможные уровней мощости может быть в границах 1:26.

Я уж не говорю и о том что под такие тесты не отводится МФ целиком. Используются партиции. В других партициях идет другая работа. Так что MF с 14 CPU это не такая же определонность как Power p550 с 4 ядрами.

Есть и еще что сказать.

P.S. Кстати, лучший response time в первой десятке тестов SAP - 0.84 sec на 64 ядрах:
IBM Power 780, 8 Processors / 64 Cores / 256 Threads, POWER7+, 3.72 Ghz, 32 KB (I) and 32 KB (D) L1 cache and 256 KB L2 cache per core, 10 MB L3 cache per core
mskmel
Уже с Приветом
Posts: 946
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: IBM PC

Post by mskmel »

zVlad wrote:Прежде ремарка: цена за 14 CPU mainframe будет существенно больше 1 миллиона.
При выборе решения это часто важный параметр.
zVlad wrote: Memory: MF - 26 GB Power - 64 GB
Это не важно, в смысле совсем. Важно соотношение цены к количеству "попугаев".
Я сомневаюсь что МФ подешевели с тех времен, за 1млн покупается 4ре Sun сервера с 64cores/512Threads/2TB RAM каждый. На х86 будет еще дешевле.
zVlad wrote: %CPU: MF - 70.34%, Power - 99% (CPU MF явно не догружен и мы далеки (на сколько не знаю) от максимума по юзерам).
Я так понял это DB2 ограничение.
DB2 10 provides constraint relief in the number of concurrent threads it can support in a single DB2
subsystem. Prior to DB2 10, our customers running SAP were pretty much limited to 400 threads per
single DB2 subsystem. To work around this limitation, they needed to use DB2 data sharing. Now, with
DB2 10, more concurrent threads can be used within a single DB2 subsystem.
We ran tests with DB2 9 and DB2 10 on a z10 12w using the SAP SD workload with 409 threads and 457
threads. We were able to successfully run 14,400 SD users on a z10 12w using 409 threads with both
DB2 9 and DB2 10. However, when we increased the user load to 16,464 SD users which required
additional threads, we could only run with DB2 10. We could not successfully run the SAP SD workload
with 457 threads with DB2 9
.
zVlad wrote: Response time: MF - 0.373 sec Power - 1.89 sec (У Мф результат лучше в почти 20 раз).
Этому объяснение в начале статьи, они взяли существенно меньшую БД для МФ теста в сравнении с тем, что обычно тестируется. Возможно потому что не смогли откопать более современный storage, да и он не требовался для требуемого тестирования (DB2v9 -> DB2v10)
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:....
zVlad wrote: %CPU: MF - 70.34%, Power - 99% (CPU MF явно не догружен и мы далеки (на сколько не знаю) от максимума по юзерам).
Я так понял это DB2 ограничение.
DB2 10 provides constraint relief in the number of concurrent threads it can support in a single DB2
subsystem. Prior to DB2 10, our customers running SAP were pretty much limited to 400 threads per
single DB2 subsystem. To work around this limitation, they needed to use DB2 data sharing. Now, with
DB2 10, more concurrent threads can be used within a single DB2 subsystem.
We ran tests with DB2 9 and DB2 10 on a z10 12w using the SAP SD workload with 409 threads and 457
threads. We were able to successfully run 14,400 SD users on a z10 12w using 409 threads with both
DB2 9 and DB2 10. However, when we increased the user load to 16,464 SD users which required
additional threads, we could only run with DB2 10. We could not successfully run the SAP SD workload
with 457 threads with DB2 9
.
....
Я как то не улавливаю логики Вашего анализа, иными словами я не вижу логики в Ваших рассуждениях на основе приведенных Вами же цитат. В цитате из теста английским по белому написано что да у DB2 9 есть ограничения по количеству threads (DB2 threads, и я добавлю - для SAP. Почему для SAP спросите? Потому что динамический SQL) и это ограничение снято в DB2 10.
Возникает вопрос: как это связанно с данными по загрузки CPU? В одном случае она 70% в другом 100%. Где логика? Я не вижу. Покажите мне ее.
В первом столбце таблицы из которой Вы взяли данные по МФ загрузка CPU близка к 100% на том же количестве всего кроме величины MAXKEEPD. Ваши комментарии?
zVlad
Уже с Приветом
Posts: 15312
Joined: 30 Apr 2003 16:43

Re: IBM PC

Post by zVlad »

mskmel wrote:....
zVlad wrote: Response time: MF - 0.373 sec Power - 1.89 sec (У Мф результат лучше в почти 20 раз).
Этому объяснение в начале статьи, они взяли существенно меньшую БД для МФ теста в сравнении с тем, что обычно тестируется. Возможно потому что не смогли откопать более современный storage, да и он не требовался для требуемого тестирования (DB2v9 -> DB2v10)
Много раз приходилось мне объяснять многим людям что при наличии правильных индексов (а порой и неправильных, но их наличии) время выполнения запроса в БД не зависит (в достаточно широких пределах) от величины ее.
Кстати, раз Вы видите причину в различии размеров БД то почему не привести числа?

P.S. не понятно мне зачем так грубо обманывать тех кто не читал и не собирался читать отчет по тестам на МФ? Неужели Вы не поняли что я прочитал этот документ внимательно и полностью. А это значит что там использовалась (откопалась) не только устаревшая память (storage) для SD теста (где это не принципиально согласно объяснениям), но и "более современная" для другого теста проведенного в том же проекте. Объясните, зачем так низко опускаться? Вы даже не смогли выбрать главное из двух предположений, а привели их оба хотя они разные. Вы даже сказали "возможно". Так что ж там по Вашему было на самом деле то? Старая storage или маленькая, по размеру, БД? Вы уж определитесь как нибудь.

Return to “Вопросы и новости IT”