New z14 mainfraime family.

[zVlad]

Да.

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

[flip_flop]

Процессы разные - кремний на изоляторе (SOI) супротив планарного кремния (bulk Si). Да даже при одном и том же названии процесса (например, bulk 14 nm) - реальная плотность может быть несколько разная у разных проиводителелей и даже у одного и того же производителя при несколько изменённом процессе (сколько и какие уровни металла). Правила проектирования разные, что тоже определяет плотность. Далее, при одном и то же процессе, как распорядится площадью - зависит от целей проектирования. Можно пожертвовать реальной плотностью в целях повышения быстродействия, например, выделив большие конденсаторы на чипе в разных местах и обесспечивая лучший температурный режим, как уже указывали. Потом, IBM вовсю использует eDRAM, это тоже ведёт к последствиям, с одной стороны- большие кеши (при меньшем числе ядер), с другой стороны- надо эту область на чипе изолировать, что ведёт к потере плотности. В общем, очень много реальных факторов, реальность - она сложнее, чем чрезмерно упрощённый подход в виде постоянной плотности, ведущей к одному и тому же числу транзисторов при одной и той же площади кристалла.

Влад - не заморачивайся деталями микроэлектроники, несмотря на всё вышесказанное - степень интеграции - подобная, подумаешь какие то 40 % разницы, ерунда в маштабах мировой революции

P.S. Влад, ты же не ожидаешь тотального убийственного универсального гармоничного превосходства ИБМ в вопросе всего сущего, включая проектирование чипов? Или всё таки - если ИБМ - то музыка небесных сфер?

P.P.S. Чёрт, дёрнул старика таки вступить в дискуссию, Сорри, ухожу...

[Flash-04]

Да.

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

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

[zVlad]

....
P.S. Влад, ты же не ожидаешь тотального убийственного универсального гармоничного превосходства ИБМ в вопросе всего сущего, включая проектирование чипов? Или всё таки - если ИБМ - то музыка небесных сфер?

P.P.S. Чёрт, дёрнул старика таки вступить в дискуссию, Сорри, ухожу...

Нет, нет, останься. Ты очень полезную информацию даешь. Спасибо.

Что касается "превосходства ИБМ в ... проектирование чипов" то ничего подобного я не ожидаю вовсе. Я хочу лишь разобраться в чем и как проекты чипов, их архитектур и возможностей различаюстся, где и какие есть барьеры. В целом, после чтения толстых книг, я увидел что собственно чип Intel вполне себе развит, даже порой излишне развит, но некоторые программные моменты мне хочется дальше прояснить, для себя и, возможно, других, чтобы лучше осознать различия.

"превосходства ИБМ" я, на самом деле, вижу в другом - в ПO, в OS, в zOS наконец. Но это, увы, не твоя сфера.

По большому счету же мне на данный момент совершенно безразлично кто, кого, чего и как - меня пенсия заждалась (в России я уже пенсионер), а там и скорый уход от дел. Так что не путайте меня с молодыми, дикорастущими специалистами, которым все надо, до всего дело есть. Я могу и готов признать любые огрехи IBM, MF, zOS. Но я хочу не на уровне price list об этом говорить, а на хорошeм профессиональном уровне и достижении общего консенсуса и согласия. Для этого я начитал материал в двух книгах не по МФ. Для этого, а не для пропаганды z14 - что было лишь хорошим поводом - я открыл эту, по-видимому последнюю, тему a la "holy wars".

[Flash-04]

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

[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. Сейчас окажется что речь идет о локальных дисках на локальной шине.

[mskmel]

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

Я просто не вижу повода для печали.

Давайте будем уважать друг друга. Если мы говорим об аргументации производительности массива не доступного на МФ, то не надо переходить на хакеров, доступность, "нам хватает и меньше" и "другие и без этого живут".
Да живут, да дирижируют джобами, да создают реплики, да допускают извращения по 30 2х портовых FC HBA (популярно было одно время) не достигая и 1/4 того что уже дал прогресс.

[zVlad]

... что уже дал прогресс.

Мы с нетерпением ждем рассказа про прогресс. На чем и как он достигнут.

[mskmel]

Мы с нетерпением ждем рассказа про прогресс. На чем и как он достигнут.

Ключевые слова Infiniband, NVMe, Linux
Вот один из примеров реализации https://www.flashgrid.io , в примере выше не это решение

[iDesperado]

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

мы все когда-то жили на устаревшей технике и примитивных модемах, но теперь с таким отстоем живете только вы в мире МФ. и не надо вашу систему воспринимать как нечто серьезное, у вас все буферные кеши вместе взятые 3.3Gb, попадание в 87%, откуда там нагрузка на ио может взяться ? взгляните на современный мир, в мобильном телефоне samsung s8 сейчас 4Gb, у вас буферный кеш 3.3Gb.

[zVlad]

..... у вас все буферные кеши вместе взятые 3.3Gb, попадание в 87%, откуда там нагрузка на ио может взяться ? взгляните на современный мир, в мобильном телефоне samsung s8 сейчас 4Gb, у вас буферный кеш 3.3Gb.

Ты уже второй раз в этой теме приводишь какие-то числа безотносительно того что обсуждается. Придется удовлетворить твое упорство.
Во-первых, не кеши, а пулы. Это называется в DB2 Buffer Pool, и я тебе уже несколько раз говорил об этом.
Тот, один из буферных пулов (BP1 по видимому), про который ты говоришь, стал с тех пор несколько больше. А вообще можешь сам посчитать каков суммарный размер всех наших BP:

Code: Select all

+ Pool     VP       Pages    Pages    Getp       Read       Prefetch   Write
+ ID       Size     Alloc    In Use   Rate       I/O Rate   Req Rate   I/O Rate
+ ------   ------   ------   ------   --------   --------   --------   --------
+ BP0       25000    25000     1355     438.00        .00       1.33        .00
+ BP1      900000   900000     6474   13751.66      70.00      52.66        .00
+ BP2      800000   800000    13391   42536.66     232.66     541.00        .00
+ BP3        5000     5000        2      53.00        .00       3.00        .00
+ BP4       12000    12000        2    1395.00        .00      11.33        .00
+ BP5        9500     9500      278     178.66        .00        .33        .00
+ BP6      405000   405000     1268      42.33        .00        .00        .00
+ BP7      100000   100000    48240    2127.66        .00        .00        .00
+ BP10     150000   150000      285     107.33        .00       3.33        .00
+ BP11     600000   600000      624     844.66        .00      80.33        .00
+ BP13     300000   300000       21   16108.66        .00    2947.66        .00
+ BP14       1500     1500       11        .00        .00        .00        .00
+ BP32K     10000    10000       87      23.00        .33       3.00        .00
+ BP32K7    50000    50000    28922      19.33        .00        .00        .00
+ BP8K0     20000    20000        1     260.33       1.33       5.00        .00
+ BP16K0      500      500        0      71.00        .00        .66        .00

I/O - это главный киллер response time. Во всех применениях БД для OLTP (строго говоря, и это видимоо ввело некоторых в заблуждение, наше ERP приложение не чисто OLTP, который имеет дело с очень короткими транзакциями согласно теории. У нас весьма широкий спектр транзакций используется, есьть и такие что их можно смело отнести к OLAP) делаются попытки как можно больше данных поместить в память и мксимально сократить I/O. Мы не исключение.

Буфферные пулы, которые ты видишь выше, специальным образом формировались и настраивались, в большенстве их сидит по одной таблице (hit ratio в них 99% как правило, поскольку все данные находятся в пуле), в каких то по нескольку, а в BP1 все остальные таблицы (hit ratio здесь самый низкий 70-80%%) и в BP2 все индексы. Конечно все данные из БД мы в память загнать не можем - у нас всего в продакшн 24 GB RAM поэтому без ввода-вывода не обойтесь, но он сведен, намеренно, к минимуму. Я ни разу не видел чтобы наши каналы ввода-вывода были загружены больше чем на 10%. И в тоже время CPU в пиковые часы трогает планку в 100%, вот, специально для тебя - ты видно любишь анализировать данные мониторинга с МФ - позавчерашний сумарный отчет по CPU:

Code: Select all

                                               R M F   S U M M A R Y   R E P O R T

            z/OS  V1R13              SYSTEM ID ****             START 09/27/2017-07.00.00  INTERVAL 00.29.59
                                     RPT VERSION V1R13 RMF      END   09/27/2017-16.00.00  CYCLE 6.000 SECONDS

NUMBER OF INTERVALS 18            TOTAL LENGTH OF INTERVALS 08.59.50
DATE   TIME     INT   CPU   DASD  DASD   JOB   JOB   TSO   TSO   STC   STC  ASCH  ASCH  OMVS  OMVS SWAP DEMAND
MM/DD HH.MM.SS MM.SS  BUSY  RESP  RATE   MAX   AVE   MAX   AVE   MAX   AVE   MAX   AVE   MAX   AVE RATE PAGING
09/27 07.00.00 29.59  32.6   1.9 367.0     6     0     2     1   112   112     0     0     4     3 0.00  17.67
09/27 07.30.00 29.59  53.9   2.0 538.2     4     0     2     2   112   112     0     0     4     3 0.00   2.47
09/27 08.00.00 30.00  52.0   2.0 478.0     3     0     3     3   112   112     0     0     4     3 0.00   0.98
09/27 08.30.00 30.00  54.8   1.8 658.4     3     0     8     5   112   112     0     0     4     3 0.00   0.89
09/27 09.00.00 29.59  57.7   1.7 667.2     4     0     8     8   112   112     0     0     4     3 0.00   5.70
09/27 09.30.00 30.00  77.8   1.9 590.9     7     1    10     8   113   111     0     0     5     3 0.00   0.39
09/27 10.00.00 29.59  70.8   2.1 656.0     7     1    10     9   113   112     0     0     5     3 0.00   0.20
09/27 10.30.00 30.00  66.5   1.8 788.5     5     0    10     9   113   112     0     0     4     3 0.00  25.55
09/27 11.00.00 29.59  64.4   2.0 635.1     4     0    10     8   112   112     0     0     5     3 0.00   6.45
09/27 11.30.00 29.59  50.2   2.0 569.6     4     0    10     8   112   112     0     0     4     3 0.00   3.92
09/27 12.00.00 30.00  36.9   2.3 404.1     4     0    10     7   112   112     0     0     5     3 0.00   2.77
09/27 12.30.00 29.59  43.7   2.4 453.4     4     0     7     6   112   112     0     0     4     3 0.00   1.40
09/27 13.00.00 29.59  56.6   2.2 528.8     4     0     9     8   112   112     0     0     4     3 0.00   1.93
09/27 13.30.00 29.59  67.9   2.1 671.6     5     1    11     9   112   111     0     0     4     3 0.00   0.37
09/27 14.00.00 29.59  59.2   2.6 576.5     5     0    12     9   112   112     0     0     5     3 0.00  10.68
09/27 14.30.00 30.00  53.9   1.9 550.7     3     0     6     5   112   112     0     0     5     3 0.00   0.85
09/27 15.00.00 30.00  52.7   2.3 496.4     2     0     9     7   112   112     0     0     4     3 0.00   1.58
09/27 15.30.00 30.00  33.2   3.4 426.2     3     0    11     9   113   112     0     0     4     3 0.00   0.38
TOTAL/AVERAGE         54.7   2.1 558.7     7     0    12     7   113   112     0     0     5     3 0.00   4.68