Миф: как IBM победил БЭСМ

[StrangerR]

Возвращаясь к старым ЭВМ
https://ru.wikipedia.org/wiki/%D0%A1%D0 ... %B5%D1%80)
Единственный троичный компьютер, но

один трит записывался в два двоичных разряда, четвёртое состояние двух двоичных разрядов не использовалось

то есть на самом деле это была не троичная система, а неэффективно используемая двичная
Кому это было надо?
Извращение же

Ничего не извращение.

Да , НЕТ, Не-Знаю

Как раз три состояния

[zVlad]

Все это так, вот только когда эта же БД с этим же прикладом пойдет на Юникс/Oracle то речь будет идти о нескольких серверах, десятках коров (если не сотне) и сотнях GB memory.

ну давайте все же разберемся с чем вы те 10 cpu спутали. покажите, что показывает команда prtconf

Короче дружбан мой появился, но говорит Клиент2 ушел с нашего сопровозгдения вот уже год как. Так что доступа у него к тем серверам нет.
Тем не менее мне есть что сказать.
Кстати та конфигурация где были 20 коров (не CPU в Вашем понимании, а именно коров в Вашем же понимании. Я же всегда говорил что CPU = кор) эта была первая конфигурация на которую Клиент2 соскочил непосредствненно с МФ (напомню - 2 CPU, 7438 MB, 458 MIPS старый MF начала 2000-x, старый конечно по нынешним временам, соскочили они в 2008).
Когда мы с Вами пару лет назад бодались (точнее Вы бодались со мной) Клиент2 был еще на той первоначальной конфигурации, но уже собирался переехать на новую. Видимо после пеезда Клиент2 и отказался от нас.
Тем не менее картинку с новой конфигурацией дружбан мне прислал.

Зная Вас, iDesperado, я еще раз скажу - все сервера задействованы ровно на одно приложение, написанное тем же вендоров что пишет его и для МФ, причем пишет он его именно в конфигурации Юникс/Oracle и лишь потом портирует на МФ в zOS/DB2/CICS.

Так вот на картинке 5 физических серверов все IBM p750. Два сервера 12x3.7GHz, 256GB, один 16x3.6GHz/256GB, и два 16 x3.6GHz/128GB.

На первых двух серверах (12x3.7GHz, 256GB) x 2, сидит продaкш в виде хитрой смеси кластера i Standby.Kаждый сервер имеет 5 PLAR. Два по 5 коров и по 110 GB (5 Cores 110 GB Mem.) , и три микроскопических LPAR из остатков ресурсов (1 Cores 25 GB Mem, и два - 0.5 Cores 2 GB Memory).

Как я понимаю в 4-x LPAR ранятся 8 кусков: 2 active BD, 2 standby BD, 2 Active App Server, и два StandBy App. servera, таким образом что в каждом LPAR сидят один Active AppServer и standby BD и наоборот. Каждая активная пара обединена в кластер на базе двух серверов (или LPARs на разных серверах).

Таким образом Production использует 5x4 = 20x3.7GHz и 110x4 = 400 GB). Сравните с параметрами МФ с которогo они соскачили (см. выше). Плюс не-Production сервера: 2x16= 32х3.6GHz 256+128 = 384 GB. Total: 52x3.7GHz 784GB. По нe-Production у меня есть дополнения, но посмотрим как будет развиваться дискуссия.

[iDesperado]

Влад, это не серьезно.
1. p750 оснащается 3.55Ghz и 4.0Ghz процессорами
2. p750 не бывает с 12 ядрами, бывает с 8 и 16, 32
3. 485MIPS/8Gb это в лучшем случае эквивалент LPAR на 8 lcpu (2 ядра power7), факты миграций реальных систем суровы и в отличие от ваших рассказов хорошо задокументированы.

[StrangerR]

Ну так, они просто за те же деньги поставили в 10 раз больше памяти, остаток заплатят теперь быдлокодерам и вместо аккуратного вылизанного кода будут писать быдлокод. Но за счет 400 гигов памяти и кучи процессоров этот быдлокод работать будет быстрее чем работала МФ, денег они заплатят меньше, и все будут доволны. Хотя красоты будет много меньше.

Проходили уже, так же плакали глядя как вместо красивых C++ программ приходят уродливые монстроидальные жаба коды написанные не поймешь кем и не поймешь под какой дозой марихуаны.. Тем не менее, C++ все меньше а жабы все больше.

[avitya]

Ну так, они просто за те же деньги поставили в 10 раз больше памяти, остаток заплатят теперь быдлокодерам и вместо аккуратного вылизанного кода будут писать быдлокод. Но за счет 400 гигов памяти и кучи процессоров этот быдлокод работать будет быстрее чем работала МФ, денег они заплатят меньше, и все будут доволны. Хотя красоты будет много меньше.

Проходили уже, так же плакали глядя как вместо красивых C++ программ приходят уродливые монстроидальные жаба коды написанные не поймешь кем и не поймешь под какой дозой марихуаны.. Тем не менее, C++ все меньше а жабы все больше.

Нечего про марихуану. Под ней отличный код идёт.

[oshibka_residenta]

StrangeR, скучный Вы человек - ни о чем кроме цен говорить не можете.

Надо срочно переходить в sales. Такой талант пропадает. В приложении со способностью нести разумный BS на технические темы - sky's the limit.

[StrangerR]

StrangeR, скучный Вы человек - ни о чем кроме цен говорить не можете.

Надо срочно переходить в sales. Такой талант пропадает. В приложении со способностью нести разумный BS на технические темы - sky's the limit.

Кому из нас двоих? Или обоим, а лучше в паре работать? А что, я думаю я найду способ МФ впарить. Или наоборот, 100 интелов впарить .

нести разумный BS на технические темы

Интересно, а если этот BS еще и практически - работает (в форме скриптов, дата центра и прочего) - это BS или не особо?

[oshibka_residenta]

Кому из нас двоих? Или обоим, а лучше в паре работать? А что, я думаю я найду способ МФ впарить. Или наоборот, 100 интелов впарить

Я про zVlad. Мне кажется он смог бы впарить решение за бОльшие деньги.
А у вас как-то мелковато - какие-то все расчет. Таким клиента не поразить. Но вы тоже терзайте.

[zVlad]

Сегодня случился такой порадокс в нашей конторе. Утром мой тим лид сообщает на тестовой системе сидит batch job с одним ad-hoc query к DB2, уже 20 часов сидит. Смотрю query, что-то вроде вот такого:

Select distinct c1 from table1 t1
where t1.TIME_STAMP > '2014-10-26-.....'
and ((Not Exists (select 1 from table2 t2
where t1.c2 = t2.c2)
Or Not Exists (select 1 from table3 t3
where t1.c2 = t3.c2)
Or.........
Or Not Exists (select 1 from table7 t7
where t1.c2 = t7.c2)))

а рядом коллега погодился, наш из Минска, программист на Wintel, говорит давай я этот query в реплике нашей DB2на MS SQL прогоню (я рассказывал про эту реплику), пришли мол мне его по e-mail. Шлю, отвечает - 18 секунд выполнения на реплике этой же самой BD что на MF, только под MS SQL на Intel server. А на МФ за 21 час не прошло, канцелировали вручную. Кстати query в плане подготовки к переносу на MF BD с Oracle (тоже рассказывал об этом раньше).

Начинаю искать в чем дело. смотрю на стороне MF. Вижу по именам таблиц что это весьма крупные таблицы (помню со времен DBA-ства). Вижу что индекса на столбце TIME_STAMP нет, индекс на столбец c2 только в двух таблицах из семи. Спрашиваю коллегу из Минска, а что там у вас на MS SQL, не знаю говорит, пришлю MS SQL DBA. Приходит MS SQL DBA, наш из Москвы, спрашиваю, отвечает у них индексы есть на все причинные столбцы. А какой у вас сервер, сколько чего. Отвечает 24 GB (у нас 8GB в тестовом LPAR), 32 кора (у нас 3 кора, правда МФ-ских).

Сегодня наша DB2 DBA, когда я уходил, создавала нужные индексы. Завтра будем посмотреть и рассказать.

[tengiz]

Сегодня случился такой порадокс в нашей конторе.

А в чем парадокс? Запрос с таблицами где есть, возможно, все полезные индексы на системе у которой в разы больше памяти и ядер выполнился заметно быстрее, чем запрос, возможно, без всех полезных индексов на системе с меньшей памятью и ядрами. Я бы ожидал, что это как раз вполне предсказуымый результат если таблица t1 реально большая и если данных там хотя бы за несколько месяцев и предполагая что по датам данные распределены более-менее равномерно и, следовательно, условие "where t1.TIME_STAMP > '2014-10-26-...." может уменьшить объем данных прочитанных из таблицы t1 в десятки или даже сотни раз при наличии правильного индекса.

[zVlad]

Сегодня случился такой порадокс в нашей конторе.

А в чем парадокс? Запрос с таблицами где есть, возможно, все полезные индексы на системе у которой в разы больше памяти и ядер выполнился заметно быстрее, чем запрос, возможно, без всех полезных индексов на системе с меньшей памятью и ядрами. Я бы ожидал, что это как раз вполне предсказуымый результат если таблица t1 реально большая и если данных там хотя бы за несколько месяцев и предполагая что по датам данные распределены более-менее равномерно и, следовательно, условие "where t1.TIME_STAMP > '2014-10-26-...." может уменьшить объем данных прочитанных из таблицы t1 в десятки или даже сотни раз при наличии правильного индекса.

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

[tengiz]

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

Теперь понятно. Для такого запроса если оптимизатор выберет hash anti-join вместо nested loop/merge anti-join самым главным ресурсом для скорости может оказаться память, а не индексы.

[zVlad]

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

Теперь понятно. Для такого запроса если оптимизатор выберет hash anti-join вместо nested loop/merge anti-join самым главным ресурсом для скорости может оказаться память, а не индексы.

Я сейчас создаю индексы, их никто не промялся создавать оказывается. Там посмотрим.

[zVlad]

После создания индексов лучшee время выполнения запроса упомянутого в начале страницы стало 20-40 секунд. 20 секунд выполнение в выводом первых 10 строк, 40 секунд с полным выводом - около 1000000 строк. См. столбец "Elapsed Time":

Code: Select all

+                                  Elapsed  CPU                          Term
+ End Time       Plan     Authid   Time     Time   SQL   Commit Abrt Pkg Status
+ ------------   -------- -------- -------  ------ ----- ------ ---- --- ------
+ 22:27:01.208   DSNESPUR SIVB       20.02  19.722    15     3     0   1 DEALLOC
+ 22:25:37.617   DSNESPUR SIVB       41.01  39.591  937K     3     0   1 DEALLOC
+ 22:24:17.839   DSNESPUR SIVB       40.58  39.227  937K     3     0   1 DEALLOC
+ 22:23:00.978   DSNESPUR SIVB       41.36  39.774  937K     3     0   1 DEALLOC
+ 22:21:02.016   DSNESPUR SIVB         .01    .000     4     1     0   1 DEALLOC
+ 22:19:54.000   DSNTEP91 SIVB       35.18  34.689  937K     1     0   1 DEALLOC
+ 22:18:20.031   DSNTEP91 SIVB       40.65  39.009  937K     1     0   1 DEALLOC

Запрос в MS SQL был не совсем на тех же данных что использую я сейчас. Тот запрос давал ~ 220000 строк. Этот почти миллион строк.

[StrangerR]

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

Теперь понятно. Для такого запроса если оптимизатор выберет hash anti-join вместо nested loop/merge anti-join самым главным ресурсом для скорости может оказаться память, а не индексы.

Я сейчас создаю индексы, их никто не промялся создавать оказывается. Там посмотрим.

А у вас что, можно просто взять и _создать индекс_? А по рукам не дают??

Создание индекса - это изменение. Изменение должно быть записано в виде скрипта, протестировано, желательно чтобы еще ДБА глянул, а потом только _скрипт_ выполнен в продакшене, с аппрувелом изменения. А прросто _ДБА пошел и создал_ вообще говоря - так и базу убить можно. Индексы то, они что-то ускоряют а что-то замедляют, и по уму если индекс не _просто потеряли_ - нужно перфоменс тесты прогонять.