Ещё одна священная война: mainframes vs x86 servers

dB13
Уже с Приветом
Posts: 1494
Joined: 08 May 2001 09:01
Location: Silicon Valley

Post by dB13 »

Palych wrote:Зачем искусственно ограничивать размер памяти, когда она дешевле грязи узге? В чём проблема "Большой" памяти?


"Большую" память нельзя разместить рядом с процессором, поэтому у неё большие задержки. Локальная (но маленькая) cache память с этим борется, но результаты -- так себе.
dB13
Уже с Приветом
Posts: 1494
Joined: 08 May 2001 09:01
Location: Silicon Valley

Post by dB13 »

zVlad wrote:А вот у меня такой вопрос есть к архитектуре сервера на базе x86. Возможно ли чтобы у разных виртуальных адресных пространств были такие страницы, или сегменты памяти, которые бы отображались на одни и те же физические страницы (сегменты).
Только пожалуйста не говорите просто "да, имеется" (если конечно имеется. Дайте свое понимание этого механизма.
В системах на МФ (в z/OS или z/VM) это широко используется когда участки виртуальной памяти разных процессос (ВМ) на самом деле представленны одной и той же физической копией.


Да, имеется. Я уже давал эту ссылку.
http://www.usenix.org/events/osdi02/tech/waldspurger/waldspurger_html/node8.html
dB13
Уже с Приветом
Posts: 1494
Joined: 08 May 2001 09:01
Location: Silicon Valley

Post by dB13 »

flip_flop wrote:
dB13 wrote:Виртуализация была последним большим преимуществом МФ перед х86/х64 серверс.

Вперед в прошлое - какая виртуализация (в каком контексте) снимает это преимущество МФ?


Виртуализация процессора -- позволяет поднять среднею загрузку процессоров с 5%-20% до 50%-90%.




> I Виртуализация со стороны пользователя
> 1) Многозадачность - почему недостаточно просто ее ?
1.1 Mногие программы плохо написаны (особенно на Windows) и наступают друг на друга и на существенные части конфигурации ОС.
1.2 Виртуализация даёт дополнительную перегородку для разделения доступа.
1.3 Виртуализация позволяет управлять ресурсами для ОС и программ, которые этого сами не умеют.
1.4 Виртуализация позволяет инкапсулировать и переносить на другое железо всю ОС со всеми программами с минимальными проблемами.

> 2) Наличие нескольких образов одной и тоже ОС - надо ли и насколько важно?

Надо и важно.

> 3) Наличие нескольких разных ОС - насколько важно в контексте главного вопроса о "добивании МФ" :wink: (как пользователь лаптопа я бы хотел полноценного эффективного использования паралельно Линукса и Виндовса - тут нер вопросов)

Да - очень важно. Большие компании обычно используют сборную солянку из ОС: DOS, Win95, NT4, Windows 2000, 2003, x32, x64, Linux 2.2, 2.4, 2.6, Netware, x86/x64 Solaris.

> II Виртуализация ресурсов ИО
> 4) представление физического интерфейса ИО его виртуальным образом (как для агрегации /много физических в один виртуальный/ так и для расшаривания /один физический в много виртуальных/) - насколько важно ?

Да, важно для улучшения загрузки и повышения надёжности (multipath, teaming. etc.)

> 5) виртуальная подмена одного типа ИО другим типом ИО (подстройка универсального физического ИО под разные виртуальные ИО) - насколько важно в контексте общей победы?

Очень важно -- позволяет инкапсулировать и переносить на другое железо всю виртуальную машину.
dB13
Уже с Приветом
Posts: 1494
Joined: 08 May 2001 09:01
Location: Silicon Valley

Post by dB13 »

zVlad wrote:
KP580BE51 wrote:Тоже самое. Если у меня запушено куча bash, то нафига мне их всех держать в разной физической памяти?


Вот такие ответы меня как раз и не устраивают. Под таким "тоже самое" могут на самом деле скрываться совершенно разные вещи. У меня сейчас нет времени писать как это делается на МФ. Вот если бы Вы добавили несколько фраз о том как это делается на x86, то это было бы здорово.


http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f04/lectures/class18.ppt
Особенно страница 35: fork() and copy-on-write (COW).
erix
Уже с Приветом
Posts: 3289
Joined: 18 Oct 2005 18:08

Post by erix »

Flash-04 wrote:1. 386, Pentium, Core 2
2. PCI, Express
3. x64 (тут AMD был первым)
и т.д.


Ну если с большой натяжкой, то 386, Пень и x64 можно назвать "революциями". Core 2 и PCI на революцию никак не тянут, так же как SATA, USB и Hypertransport.
Более того, последней "революционной" вещью можно навать разве что "мултимедию" которая призошла когда там? в конце 90-х, что ли.

Мелковаты у вас критерии для революционности, однако
User avatar
Scrooge McDuck
Уже с Приветом
Posts: 5598
Joined: 28 Nov 2005 06:56

Post by Scrooge McDuck »

zVlad wrote:Что и ожидалось дискуссия превращается в элементарное отрицание какой-либо значимости МФ, в цены, домохозяйки, отцы работавшие в НИЦЭВТ-е в начале 70-х, в то что все архитектуры одним миром мазаны, и т.д.
Даже описание состояния технологий МФ в начале 90-х, к которому другие платформы только недавно подошли и то парой троикой фраз "низвергнуты" (зачем, говорит Скрудж, домохозяйке логические партиции).

Влад, Вы простите пожалуйста, но наперсточник Вы. В приличном обществе Вас бы уже давно уже того канделябром :-):-):-). Я ведь этого не говорил. Своего отца я привел в качетсве примера того, что в целом из IT семьи и рассказывать мне что до Интел/Виндоус были компьютеры и ОС все-таки не стоит. И под одну гребенку никто ничего не мел, все и я и Тенгиз в посте насчет различных ДБ, вполне осознаем вклад IBM в компьютерную индустрию. А пример с домохозяйками был приведен для того, что бы напомнить Вам, что комьютерная индустрия развивается не в вакууме, а в инвайроменте денег, людей и их интересов. Кому было бы нужно сказчкообразное развитие МФ если бы количество потребителей их услуг было бы как в 60 - 70-ый ? Если бы веб не появился? и так далее и так далее.
Я упорно не могу понять почему нет желания провести аналогию с тем же китаем. Да 20 лет назад, то что он делал ничего кроме усмешки не вызывало, но он (Китай) старался и делал все лучше и лучше, пока в отдельных областях не стал делать хорошо (пусть пошив джинсов) и ценой (ну есть такая характеристика) выдавил всем местным амаериканских портных. Вот скажем сейчас он стал делать машины. Да мы знаем, что китайских машины в общем-то дерьмо, но уже машины от их собратьев (корейские хундаи) уже ничего. Мерседес и Ауди по прежнему лучше, но неужели сложно посмотреть за тенденцией?
на войне только дурак строит долгие планы, на войне есть одна задача - пережить нынешний день
User avatar
Scrooge McDuck
Уже с Приветом
Posts: 5598
Joined: 28 Nov 2005 06:56

Post by Scrooge McDuck »

tengiz wrote:
Scrooge McDuck wrote:Это Вы про DB2? Прошу помощи зала. Народ, котортый DB повернутый (тенгиз, алекс_127, 8K), а чего действительно DB2 круче того же Оракла, СиБайса там, или все-таки на равных?

Примерно на равных - не в последнюю очередь из-за того, что значительная часть ключевых людей во всех главных датабазных компаниях работали в разное время в других датабазных компаниях, соответственно лучшие идеи так или иначе были реализованы более или менее везде. Однако большинство самых главных ключевых людей всё же начинали в IBM. Типичный путь датабазного авторитета: начал в IBM, потом ушёл в Tandem, потом поработал в Oracle, в итоге осел в MS. Или начал в IBM, затем со-учредил Sybase, в итоге всё равно ушёл в MS :), etc.

Т.е., как я и думал, но постеснялся произнести вслух, ничего супер фундаментального в програмном обеспечении ПО ОТНОШЕНИЮ КО ВСЕМ ОСТАЛЬНЫМ МФ предложить сейчас не могут. При этом мы помним о достижения ИБМ перед миром. Софт, програмное обеспечение, системные вещи, количество багов в конце концов (про взломы говорить не будем, поскольку МФ - это как Линукс в прошлом, его никто не ломает поскольку нет его) более - менее, как и у остальных.
на войне только дурак строит долгие планы, на войне есть одна задача - пережить нынешний день
User avatar
Scrooge McDuck
Уже с Приветом
Posts: 5598
Joined: 28 Nov 2005 06:56

Post by Scrooge McDuck »

zVlad wrote:
Scrooge McDuck wrote:..... Вы вот лично может назвать конторы где МФ появился ну если не с нуля (это как раз редкоий случай), а где произошел перэод от зоопарка (HP, Intel, Sun, etc) к МФ? Много ли таких контор?
.....

Я Вам приведу пару других личных примеров.
Один из наших клиентов вот уже года три-четыре "избавляется" от МФ. Клиент этот заморозил все апгрейды (за исключением z/OS). Клиент этот использует доисторическую версию ДБ2 - версию 6, и доисторический CICS.
Последнее что я слышал о них это то что за их миграцию на платформу Unix с них запросили такие деньги что они просто... задумались. И второе сообщение от программистов что клиент этот заказывает существенные кастомизации их приложения.

Другой пример из этой конторы где я работаю. Рассказывал мне об этом мой предшественник, работавший системщиком в середине 90-х. Тогда к руководству "подкатило" НР с предложением заменить МФ гораздо более дешевым железом. Решили тогда подойти к теме по научному: прогнать некоторый объем работы на МФ и тот же объем на НР. Не вдаваясь в детали могу сказать что результаты получились очень печальные для НР. Рассказчик ездил в командировку к НР и просто не должался окончания прогона, ему нужно было на самолет. Решение естественно было принято в пользу НР.

Влад, Вы не мудрите, Вы пальцем покажите :-):-). Какие конторы в последние годы (по мере роста из гаража в кампус в силиконке перешли на МФ)? Все Ваши примеры на сегодняшний день - это старые компании, ПРИЛОЖЕНИЯ которых уже написаны таким образом, что мигрировать на что-либо отличное от МФ ну просто не возможно. Как пример, любая миграция лондри (огромнаы стиралка, сушка, здоровенная доска для глажки) из дома в квартиру в принципе не вомзожна. При этом говорить, что покупка вятки-автомата т.е. компактной машинки для квартиры - это типа не правельно и не верно, по меньшей мере глупо. Кстати еще такой момент. 20 - 30 лет назад мощности желаза были гораздо слабее нынешних (помню у бати был IBM-286 в 1988 году с двумя дисками по 20 мегов). Может кто знает, а какой приблизительно активный обьем данных (ну т.е. без обращения к архиву на ленте) ну например какой-нибудь страховой компании за последние ну скажем 30 лет? Может уже давно проще написать ДРУГИЕ приложения иу просто конвертнуть данные (или оставить в той же самой DB2) под базу на основе интелосвких серверов? Может кто-нибудь это прокоментировать?
Что касается HP, охотно верю, что покупка новой стиралки кажется большей. Только ведь с величины суммы которую надо платить за размер ландри в доме на следующие 30 лет, сумма может уже такой огромой казатьсаы и не будет.
на войне только дурак строит долгие планы, на войне есть одна задача - пережить нынешний день
Palych
Уже с Приветом
Posts: 13731
Joined: 16 Jan 2001 10:01

Post by Palych »

dB13 wrote:
Palych wrote:Зачем искусственно ограничивать размер памяти, когда она дешевле грязи узге? В чём проблема "Большой" памяти?


"Большую" память нельзя разместить рядом с процессором, поэтому у неё большие задержки. Локальная (но маленькая) cache память с этим борется, но результаты -- так себе.

В целом мы говорим о больших системах, стало быть памяти в системе должно быть очень много, так?
Сравним 2 варианта:
1. N серверов, в каждом 16 16-ядерных CPU, 512GB памяти;
2. N*500 маленьких нодов 1CPU, 1GB.

Чем второй вариант лучше?
dB13
Уже с Приветом
Posts: 1494
Joined: 08 May 2001 09:01
Location: Silicon Valley

Post by dB13 »

Palych wrote:
dB13 wrote:
Palych wrote:Зачем искусственно ограничивать размер памяти, когда она дешевле грязи узге? В чём проблема "Большой" памяти?


"Большую" память нельзя разместить рядом с процессором, поэтому у неё большие задержки. Локальная (но маленькая) cache память с этим борется, но результаты -- так себе.

В целом мы говорим о больших системах, стало быть памяти в системе должно быть очень много, так?
Сравним 2 варианта:
1. N серверов, в каждом 16 16-ядерных CPU, 512GB памяти;
2. N*500 маленьких нодов 1CPU, 1GB.

Чем второй вариант лучше?

В среднем первый вариант лучше. Для Гугла -- второй вариант лучше -- дешевле.

Моё замечание относилось к дизайну от Dmitry67:

Сейчас есть отдельно память, отдельно процы. А что если делать их вместе в виде таких active cells: проц, небольшая память она же кеш, + энергонезависимая копия той же памяти

Что-то вроде 8 ядер с 16 MB быстрой памяти на каждый, всё -- на одном чипе.
User avatar
KP580BE51
Уже с Приветом
Posts: 15007
Joined: 14 Jun 2005 11:50
Location: Ukraine

Post by KP580BE51 »

Palych wrote:
dB13 wrote:
Palych wrote:Зачем искусственно ограничивать размер памяти, когда она дешевле грязи узге? В чём проблема "Большой" памяти?


"Большую" память нельзя разместить рядом с процессором, поэтому у неё большие задержки. Локальная (но маленькая) cache память с этим борется, но результаты -- так себе.

В целом мы говорим о больших системах, стало быть памяти в системе должно быть очень много, так?
Сравним 2 варианта:
1. N серверов, в каждом 16 16-ядерных CPU, 512GB памяти;

Технически не возможен: Точнее возможен, но вся эта куча процессоров, будет чудовищно тормозится сравнительно медленной памятью.

2. N*500 маленьких нодов 1CPU, 1GB.
Чем второй вариант лучше?

Лучше так: Кучу процессоров, каждый со своей памятью, и последовательной шиной, через которую он может копаться в памяти другого процессора. Получаем Cray XT3
zVlad
Уже с Приветом
Posts: 15420
Joined: 30 Apr 2003 16:43
Has thanked: 1 time

Post by zVlad »

dB13 wrote:
zVlad wrote:А вот у меня такой вопрос есть к архитектуре сервера на базе x86. Возможно ли чтобы у разных виртуальных адресных пространств были такие страницы, или сегменты памяти, которые бы отображались на одни и те же физические страницы (сегменты).
Только пожалуйста не говорите просто "да, имеется" (если конечно имеется. Дайте свое понимание этого механизма.
В системах на МФ (в z/OS или z/VM) это широко используется когда участки виртуальной памяти разных процессос (ВМ) на самом деле представленны одной и той же физической копией.


Да, имеется. Я уже давал эту ссылку.
http://www.usenix.org/events/osdi02/tech/waldspurger/waldspurger_html/node8.html


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

Можно еще вопрос? А в Windows используется разделение страниц разничными процессами? Как? Что в этом плане дают (если дают) DLL?
zVlad
Уже с Приветом
Posts: 15420
Joined: 30 Apr 2003 16:43
Has thanked: 1 time

Post by zVlad »

Scrooge McDuck wrote:
tengiz wrote:
Scrooge McDuck wrote:Это Вы про DB2? Прошу помощи зала. Народ, котортый DB повернутый (тенгиз, алекс_127, 8K), а чего действительно DB2 круче того же Оракла, СиБайса там, или все-таки на равных?

Примерно на равных - не в последнюю очередь из-за того, что значительная часть ключевых людей во всех главных датабазных компаниях работали в разное время в других датабазных компаниях, соответственно лучшие идеи так или иначе были реализованы более или менее везде. Однако большинство самых главных ключевых людей всё же начинали в IBM. Типичный путь датабазного авторитета: начал в IBM, потом ушёл в Tandem, потом поработал в Oracle, в итоге осел в MS. Или начал в IBM, затем со-учредил Sybase, в итоге всё равно ушёл в MS :), etc.

Т.е., как я и думал, но постеснялся произнести вслух, ничего супер фундаментального в програмном обеспечении ПО ОТНОШЕНИЮ КО ВСЕМ ОСТАЛЬНЫМ МФ предложить сейчас не могут. При этом мы помним о достижения ИБМ перед миром. Софт, програмное обеспечение, системные вещи, количество багов в конце концов (про взломы говорить не будем, поскольку МФ - это как Линукс в прошлом, его никто не ломает поскольку нет его) более - менее, как и у остальных.


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

Все что касается внутренних механизмов БД тут разница будет колосальной если даже мы будем сравнивать DB2 for z/OS с DB2 же, но для LUW (Linux, Unix, Windows) и эта разница как раз и обуславливатся принципиальными отличиями архитектуры и принципов работы МФ от архитектур на x86 и RISC.
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Post by Dmitry67 »

Тогда огласите PLS список принципиальных отличий работы DB2 и SQL/Oracle
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
zVlad
Уже с Приветом
Posts: 15420
Joined: 30 Apr 2003 16:43
Has thanked: 1 time

Post by zVlad »

Dmitry67 wrote:Тогда огласите PLS список принципиальных отличий работы DB2 и SQL/Oracle


Этот список будет списком отличий архитектуры и принципов работы МФ от архитектуры и принципов работы серверов на x86 и/или RISC.

Не верю я в успех этого мероприятия, хотя бы потому что мы с Вами Дима уже много на эту тему дебатировали, а Вы снова меня об этом спрашиваете.
Ну хорошо, первое что пришло в голову - list prefetch.

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