New z14 mainfraime family.

[Flash-04]

Влад, Интел x86 тащит за собой тяжёлое наследие совместимости с древним 8086, который был очень далек от совершенства. Помнится была попытка уйти от этого - Itanium, провалилась.

[zVlad]

Да.

Можете указать страницу в толстой книжке где описано как?

Могу, но она больше чем телефон с которого я пишу, не лезет. Влад, ну в самом деле?!

Ладно сам покопаюсь, еще надеюсь на sfbaguy1.
A книга то всего ~10 MB: 64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf

[Flash-04]

Я про страницы, а не мегабайты

[zVlad]

Влад, Интел x86 тащит за собой тяжёлое наследие совместимости с древним 8086, который был очень далек от совершенства. Помнится была попытка уйти от этого - Itanium, провалилась.

Это мне известно, но это лишь Real mode обосновывает, ну и DOS VM. Это капля в море согласно sfbaguy1. Там много было наворочено (и похоже без надобности) и во времена 286, 386 и когда вопрос виртуализации встал ребром. Я, например, очень удивляюсь и хотел бы понять специальным инструкциям и режиму работы виртуализации. На МФ (а все просто легче познавать в сравнении) ничего этого не потребовалось для построения виртуальных машин уже через три года после ананса S/360 - самого первого поколения МФ, и до появления второго.

[flip_flop]

Влад, прости старика, погорячился.

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

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

[Flash-04]

В комиксах!

[flip_flop]

Это капля в море согласно sfbaguy1.

Это действительно капля в море. Миллиарды транзисторов сейчас, как никак.

Кстати, насчёт сложности из-за поддержки разнообразного зоопарка ISA - сложность оправдана, ибо она обеспечивает производительность для широкого универсального спектра применений. Я, например, могу в разы повысить мои числодробилки разными гитиками. Эволюция вообще движется в сторону универсальности сложных организмов. Сравните человека и динозавра, например.

[mskmel]

Далее, а что такое нынче нормальный сторидж и почему Вы считаете что его у МФ нет (подробнее ниже)?

Вот это считается нормальным, т.е. на рынке несколько лет. Всё вместе и серверы, и система хранения занимают стойку. Чтобы на МФ такое получить в теории, надо сам МФ с ~100 штук 16Gb портов и ТРИ штуки DS8888, т.е. минимум 4 шкафа в сумме с кучей кабелей между ними.

Возьмем 1ТБ таблицу для экспериментов.

Code: Select all

SQL>select sum(bytes)/1024/1024 from dba_segments where owner='XX' and segment_name='YYYY';
        GB
----------
1115.62714

И прочитаем весь 1ТБ.

Code: Select all

SQL>select /*+ full(a) parallel(a,64) */ count(*) from XX.YYYY a;
  COUNT(*)
----------
5,XXX,XXX,XXX

Elapsed: 00:00:07.46
...
146025908  physical reads
...
--149GBs
--19,574,518 reads\sec

[zVlad]

Интересно, "десятки тысяч виртуальных машин". Мне это напоминает басню про скорняка который сшил 40 шапок из шкурки. Какая разница сколько вы VM забабахаете, все равно процессорная мощность от этого не увеличится, а накладные расходы съедят приличную часть производительности.

Это очень на самом деле серьезный момент.
Помню holy wars между мэйнфрэймовскими MVS-совцами и VM-щиками. Я относился ко второй группе и это было в конце 80-х, тридцать лет назад. Под VM мы гоняли две ОС: CMS - ОС для персональной виртуальной машины, и БОС (БАЗОВАЯ ОПЕРАЦИОННАЯ СИСТЕМА) - адаптированный для виртуальной машины гибрид из MVS и предыдущих ОС МФ, сделанный в НИЦЭВТ. Обе системы имели высокий уровень совместного использования кода, так что добавление новых виртуалок не влекло за собой кратное увелечение, скажем так памяти. Иными словами первая загрузка ОС на любой виртуалкe послe загрузки VM сопровождалась созданием полного имиджа ОС в памяти VM. Последущие загрузки этой же ОС в других виртуалках сопровождались построением только тех участков памяти, которые не могут быть использованы из одного экземпляра в памяти. (Я знаю что и на Интел есть такая возможность, но насколько она используется?). В VM есть такой специальный процесс - создание хранимых систем и разделяемых сегментов памяти. Как правило мы имели одну хранимую систему CMS, и одну БОС, с которых все виртуалки для этих ОС и загружали их. Таким образом каждая виртуалка состояла из того что уникально для них и приличного объема совместо используемых данных и кода. Грубо говоря ядро ОС для всех виртуалок использующих эту ОС было одно на всю VM.

В Канаде я полностью погрузился в MVS. Это не виртуальные машины, но я увидел тоже самое что описано выше, только ОС в MVS одна - MVS. Это довольно упрощенное, но достаточное для целей этого разговора сравнение.

Главным отличием того что мы имеем в VM и в MVS является то что VM НЕ ЗНАЕТ что происходит внутри виртуалок, а MVS ЗНАЕТ что происходит в крупных приложениях (БД, веб сервера, CICS и т.д.) и может использовать это знание для более интелектуального управления.

К чему я это все говорю? Не важно как мы назовем прикладные процессы, как организуем их запуск и управление. Важно какая степень разделения (share) кода и данных, как происходит взаимодействие различных единиц выполнения.

Dockers - в мире систем на х86 это как раз то как поняли, осознали, эти обстоятельства разработчики. Счет этих единиц ведется в больших числах. Это Вас не напрягает? Вот и десятки тысяч ВМ на МФ не должны напрягать, там издержки сведены к минимуму.

Я мог бы объяснить это на уровне принципов работы процессора МФ, но думаю это будет излишне, если конечно не возникнет здорового интереса у кого-нибудь.

[zVlad]

...

Возьмем 1ТБ таблицу для экспериментов.
...

Я не догоняю. Честно. К чему Вы это все, тем более не верно ни про МФ ни про сервера.
У нас, например, дисковые подсистемы для МФ и серверов это одни и те же шкафы. Наши МФ подключены ровно четырьмя оптоволоконными кабелями к этим шкафам. Остальное внутри этих шкафов.

[mskmel]

Далее, а что такое нынче нормальный сторидж и почему Вы считаете что его у МФ нет (подробнее ниже)
...
Я не догоняю. Честно. К чему Вы это все

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

У нас, например, дисковые подсистемы для МФ и серверов это одни и те же шкафы.

Ключевое тут "у нас".

[zVlad]

Далее, а что такое нынче нормальный сторидж и почему Вы считаете что его у МФ нет (подробнее ниже)
...
Я не догоняю. Честно. К чему Вы это все

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

У нас, например, дисковые подсистемы для МФ и серверов это одни и те же шкафы.

Ключевое тут "у нас".

Давайте будем уважать друг друга. Если Вы пишите мэйнфрэймщику что "нормальную производительность дискового массива на МФ не получить без извращений" то Вы обязаны дать аргументированные объяснения. Где они?

[mskmel]

Давайте будем уважать друг друга. Если Вы пишите мэйнфрэймщику что "нормальную производительность дискового массива на МФ не получить без извращений" то Вы обязаны дать аргументированные объяснения. Где они?

Выше почитайте пожалуйста. Возьмите калькулятор, и посчитайте как и чего будет стоить подключить к МФ сторидж дающий приложению возможность читать БД со скоростью 150ГБ\сек.
Хинт: ваши 4ре кабеля (скорее всего 8Гб) дают в 50 раз меньше.

PS: Гб - Гигабиты. ГБ - ГигаБайты

[Easbayguy]

Давайте будем уважать друг друга. Если Вы пишите мэйнфрэймщику что "нормальную производительность дискового массива на МФ не получить без извращений" то Вы обязаны дать аргументированные объяснения. Где они?

Выше почитайте пожалуйста. Возьмите калькулятор, и посчитайте как и чего будет стоить подключить к МФ сторидж дающий приложению возможность читать БД со скоростью 150ГБ\сек.
Хинт: ваши 4ре кабеля (скорее всего 8Гб) дают в 50 раз меньше.

PS: Гб - Гигабиты. ГБ - ГигаБайты

Не могли бы вы подробнее рассказать какой это storage и сколько его такого быстрого.

[zVlad]

Давайте будем уважать друг друга. Если Вы пишите мэйнфрэймщику что "нормальную производительность дискового массива на МФ не получить без извращений" то Вы обязаны дать аргументированные объяснения. Где они?

Выше почитайте пожалуйста. Возьмите калькулятор, и посчитайте как и чего будет стоить подключить к МФ сторидж дающий приложению возможность читать БД со скоростью 150ГБ\сек.
Хинт: ваши 4ре кабеля (скорее всего 8Гб) дают в 50 раз меньше.

PS: Гб - Гигабиты. ГБ - ГигаБайты

Спасибо большое за ценную информацию по поводу битов и байтов. Я рад что Вы их тоже различаете. Я также очень рад что Вы можете читать БД со скоростью 150 GB/sec.
Я только не могу понять чего Вы от меня то хотите. Но чтобы поддержать беседу я открою Вам одну тайну - реальным пользователям ИТ не скорость чтения из базы данных, а другие, более понятные им, параметры важны. Например среднее время выполнения транзакций, нулевое время недоступности системы, защита от хакеров, и т.п..
Наши четыре кабеля в самый пик работы пользователя загружены не более чем на 10%. Их четыре для избыточности, а избыточность для отказоустойчивости. Чтение с дисков данных из базы данных во многих случаях идет асинхронно с выполнением запросов, всякие там разные prefetch существуют, считанные данные сохраняются в буферных пулах и в кэше дисковой системы. Мораль проста - живут как то люди и без 150GB/SEC.
Только не думайте пожалуйста что я не допускаю таких скоростей на МФ. Я просто не вижу повода для печали.
Ну вслед за Easbayguy я бы тоже хотел услышать детали Вашего теста.

P.S. не трудно догадаться к чему клонит Easbayguy. Сейчас окажется что речь идет о локальных дисках на локальной шине.