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

[Dmitry67]

Кроме того, мне кажется неправильным смещивать PROD, QA и DEV в одной машине. Это от нищеты

[zVlad]

Чтобы понять что такое MIPS я Вам могу (в который уже раз) напомнить что кампания производящая электроэнергию для провинции Ontario свое ERP приложение выполняет на не самой мощной модели класс BC, без Specialty Engines. При этом все инстанцы (состоящие из БД и аппликэйшн сервера) - для Prod, QA, Dev, Training, Sandbox и множество инстанцев про нескольких проэктов все это крутится на одном единственном МФ с сумарным размером ОЗУ - 20 GB, из которых 4 GB зарезервированно для DR LPAR с другого МФ.

И о чем это говорит? У меня больше памяти дома в компе

Может это говорит о том, как экономно МФ расходует память? Как было сказано, сейчас это никого не интересует если за копейки можно поставить 200Gb. К тому же java все равно будет жрать много

Или о том что память столь дорога, что для критического приложения купили только 20Gb?

Размер памяти в отрыве от всего остального ни о чем не говорит. Я посмотрел на наш Production есть ли страничный обмен. Его нет. Следовательного памяти в данный момент достаточно для той работы которая выполняется (DB2 и application сервера, не на Java). Т.е. если бы у нас было не 12 ГБ а 120 ГБ это в данный момент ничем бы нам не помогло. не сделало бы нас лучше.
Тем не менее у нас было в прошлом когда не хватало фaйлов для страничного обмена и мы должны были добавлять их. В тот момент дополнительные гигабайты были бы кстати. Я полагаю наш DB2 DBA уменьшила размеры DB2 Buffer Pools, чтобы не было страничного обмена, а DB2 конечно, дай ему больше памяти, мог бы напихать данных - база данных у нас несколько TB. Но стоит ли этому потакать? Тем более если SLA требования удовлетворяются. Если бы SLA не выполнялось и мы нашли бы что дополнительная память поможет, то деньги бы сразу нашлись, а так никто нас даже слушать не станет о дополнительной памяти, хоть бы она стоила $100 10 GB. И это правильно.
На тестовой системе страничный обмен имеет место быть. Следовательно 6 GB без вытеснения страниц там не хватает. Но для того и есть виртуальная память чтобы на меньшем размере ОЗУ иметь больше воображаемой памяти и выполнять работы. Кстати на тестовой машине у нас есть WebSphere, в котором правда никто не работает, а может и работает время от времени - меня это как-то мало теперь волнует. На тестовой системе есть также две DB2 с примерно десятью базами данных таких как на Production и 9 application server-ов (CICS). Всего в конфигурации Production и Test системаx имеется 3584 диска по 10 GB каждый, total ~ 30 TB.

Java у нас в данный момент не выполняется нигде на МФ (за исключением одного не используемого WebSphere), но несколько лет назад я играл с WebSphere на тестовом LPAR (6 GB на все про все). Тогда существенно помогал Specialty Engine (zIIP). Весьма существенно - в разы быстрее выполнялись Java программы, и это не удувительно нисколько. Помогли бы дополнительные GB не знаю, не уверен.

[iDesperado]

судя по всему весь BC класс сейчас запросто можно мигрировать на entry-level интел сервера и крутить приложения в эмуляторе, поместив абсолютно все активные данные в память, а на SSD оставить редко нужные старше трех-пяти лет. ведь ясно, что энергокомпании Онтарио данные старше трех-пяти лет почти не нужны. если считать Владовым методом, то на самом маленьком интел сервере уже 100 тысяч миллионов cpu, которые уж точно не проиграют даже в эмуляторе, перемалывая в оперативной памяти данные.

[Dmitry67]

Я посмотрел на наш Production есть ли страничный обмен. Его нет. Следовательного памяти в данный момент достаточно для той работы которая выполняется (DB2 и application сервера, не на Java). Т.е. если бы у нас было не 12 ГБ а 120 ГБ это в данный момент ничем бы нам не помогло. не сделало бы нас лучше.
Java у нас в данный момент не выполняется нигде на МФ

Я вас верю, все это выглядит логично
java нет, аппликация для энергетики наверное старое, из 90 годов, работает с минимальными переделками по принципу "не трогай если работает"
Новых технологий никаких
По этому и держат МФ
Все новое уже не будут делать там

[zVlad]

Кроме того, мне кажется неправильным смещивать PROD, QA и DEV в одной машине. Это от нищеты

Вы просто не знаете МФ поэтому так думаете. LPAR технология используется лет 25 если не больше, она отлажена до совершенства. LPAR думаю не требует пояснений что это такое.
Более того, нормальным было бы выполнения всего зоопарка не только на одной машине, но и в одной системе. В этом случае управление работай было бы более адекватное в том слысле что если мы отдали тестовому LPAR 20% то он все двадцать может захватить вне зависимости от того что происходит в Production s ee 80%.
Будь это все под управлением одной системы, то WLM мог отобрать у тестовых работ больше если действительно надо.

В случае с одной системой для всех работ не надо иметь избыточных копий систем (о чем говорил Vladimir1440) со всеми вытекающими последствиями.

Это вовсе ни как не связанно с какой-либо нищитой. Наоборот, глядя на зоопакр серверов (не тех о которых живописал StrangeR, купленных в магазине на Колледж стрит у китайцев, а фирменных, от IBM, от HP, и т.п., а они не дешевые) которые проплачивает наш не бедный клиент я только и имею обяснение что им некуда деньги девать. Что кстати прекрасно вписывается в цели современной экономической системы - тратить больше ии больше - иначе система умрет. Война и разрушения для этой системы как наркотик. В мирных сферах использование малоэффективных технологий вроде Wintel. Нет я не против Wintel, но в больших ИТ его широкое использование ведет к катастрофам на самом деле. Это показал наш недавний DR test, только из-за проблем связанных с Wintel мы не уложились в отпущенное щедро время.

[iDesperado]

Нет я не против Wintel, но в больших ИТ его широкое использование ведет к катастрофам на самом деле. Это показал наш недавний DR test, только из-за проблем связанных с Wintel мы не уложились в отпущенное щедро время.

сразу вспоминается одна из историй Влада, как в его канторе пять лет настраивали оракловый dataguard и так и не смогли поднять. пять лет ушло на уникальную задачу, которая успешно решалась в подавляющем большинстве студентами минимум в нескольких миллионах компаний.

[zVlad]

Я посмотрел на наш Production есть ли страничный обмен. Его нет. Следовательного памяти в данный момент достаточно для той работы которая выполняется (DB2 и application сервера, не на Java). Т.е. если бы у нас было не 12 ГБ а 120 ГБ это в данный момент ничем бы нам не помогло. не сделало бы нас лучше.
Java у нас в данный момент не выполняется нигде на МФ

Я вас верю, все это выглядит логично
java нет, аппликация для энергетики наверное старое, из 90 годов, работает с минимальными переделками по принципу "не трогай если работает"
Новых технологий никаких
По этому и держат МФ
Все новое уже не будут делать там

Спасибо за доверие, вот только аппликация не из 90-х годов, эта аппликация все время обновляется и вендор все время пытается применить новые технологии. Сама эта аппликуха выпускается для двух платформ: DB2/CICS на МФ, и Юникс/Oracle. Мы три раза переходили на новые версии в этом столетии.
Но главным образом изменения касаются интерфэйсов. На МФ много нового появляется, но наш вендор ориентируется на Oracle поэтому ничего нового на МФ не видит.
Да вендор приложения ведет свою политику так чтобы егоо клиенты ушли с МФ. Следующюю версию вендор обещает не делать для МФ. Я готовлюсь наблюдать пожар в публичном доме когда мы слезем с МФ и переползем на Юникс/Oracle. По Вашему наверняка это новая технология, но работать она будет хуже, увы. Клиент наш хлебать будет полной ложкой с этих технологий.

[zVlad]

Нет я не против Wintel, но в больших ИТ его широкое использование ведет к катастрофам на самом деле. Это показал наш недавний DR test, только из-за проблем связанных с Wintel мы не уложились в отпущенное щедро время.

сразу вспоминается одна из историй Влада, как в его канторе пять лет настраивали оракловый dataguard и так и не смогли поднять. пять лет ушло на уникальную задачу, которая успешно решалась в подавляющем большинстве студентами минимум в нескольких миллионах компаний.

Что такое "оракловый dataguard"?

[zVlad]

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

Ну вот
То есть у 1Gb таки есть цена

Чисто формально конечно есть. Если заказать, например, 20 GB добавить к имеющемуся MF, то IBM назовен кокретную сумму в долларах. Ее можно будет поделить на 20 и получить как бы цену 1 GB.

[iDesperado]

Что такое "оракловый dataguard"?

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

viewtopic.php?f=46&t=176039&hilit=%D0%9 ... 5#p5127939

[Albert_al]

Ну кто же в здравом уме EMC берет?

Наши взяли -недавно наконец то увеличили кэш с 64 гиг до 128 за почти миллион

[Albert_al]

У меня часть системы бежит на Sun T4-4 с 512GB памяти, 100TB storage читаемых очень часто и 100К селектов в секунду.

SGA сколько- половина?

[Palych]

Java у нас в данный момент не выполняется нигде на МФ (за исключением одного не используемого WebSphere), но несколько лет назад я играл с WebSphere на тестовом LPAR (6 GB на все про все). Тогда существенно помогал Specialty Engine (zIIP). Весьма существенно - в разы быстрее выполнялись Java программы, и это не удувительно нисколько. Помогли бы дополнительные GB не знаю, не уверен.

Иными словами - неизвестно как будет работать Java/Websphere on MF in production.

[Easbayguy]

У меня часть системы бежит на Sun T4-4 с 512GB памяти, 100TB storage читаемых очень часто и 100К селектов в секунду.

SGA сколько- половина?

Как положено 256ГБ.

[Easbayguy]

Кроме того, мне кажется неправильным смещивать PROD, QA и DEV в одной машине. Это от нищеты

Они не только не на одной машине, они даже не в одном дата центре.