Вопросы истории ИТ и ОС

[StrangerR]

Ну, я могу сказать, что будет с тем проектом.

Сейчас его переведут на жабу. Оставив пока на МФ на вебсфере.

Потом девелоперы взвоют, что им неудобно отлаживаться на МФ и девелопент переедет на линукс.

Потом глюкалина станет потреблять 5, 10, 20 гигов памяти. На процесс.

Потом в какой то момент когда встанет вопрос докупать ли железо на МФ, начальство перетащит проект на Интел Серверы и Линуксы.

Наблюдаем сейчас в одной весьма известной иншуранс компании. Процесс в середине но уже пошел. Разработка давно уже не на МФ.

[iDesperado]

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

[zVlad]

Ну, я могу сказать, что будет с тем проектом.

Сейчас его переведут на жабу. Оставив пока на МФ на вебсфере.

Потом девелоперы взвоют, что им неудобно отлаживаться на МФ и девелопент переедет на линукс.

Потом глюкалина станет потреблять 5, 10, 20 гигов памяти. На процесс.

Потом в какой то момент когда встанет вопрос докупать ли железо на МФ, начальство перетащит проект на Интел Серверы и Линуксы.

Наблюдаем сейчас в одной весьма известной иншуранс компании. Процесс в середине но уже пошел. Разработка давно уже не на МФ.

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

Девелоперы могут конечно захотеть разрабатывать не на МФ. Ну и пусть себе разрабатывают где им удобно. Но благодаря свойствам Java эти их разработки могут выполняться и на МФ без каких-либо сложностей. Да Java жрет память как свинья помои, но это более критично на x86 и Power и менее критично на МФ.

[StrangerR]

Я не понял как это - Да Java жрет память как свинья помои, но это более критично на x86 и Power и менее критично на МФ.

На x86 это не проблема. Сервер с 256 гигами памяти стоит где то под $9K, я только что поставил в 2 дата центра 15 штук таких. Жрет и жрет, дадим сурку картошки, авось лопнет.

А на МФ сколько стоит добавить 128 гигов памяти, ась?

(Я тут посчитал несколько проектов. Под среднего кастомера навроде среднего размера иншуранс компании, общий ресурс девелоперских систем выходит где то под 2 - 4 терабайта оперативной памяти. НА ОДИН ПРОЕКТ, блин! Какой нафиг еще МФ?? А потом кастомер, увидев что у него за одни и те же деньги в девелопменте 2 терабайта а на его старой как говно мамонта и дико дорогой ибм машине - 128 гигов (или 64? Сколько там память то стоит?), начинает думать о переходе на РедХат6. И ведь перейдет, гад, и загнется бизнес МФ с ним у ИБМ!)

Только не предлагайте разогнать всех индусских кодеров и нанять программистов с Марса и переписать все на C++ (нет, у нас индусов нет, но проекты общие и у клиентов их полно... и понятие _память надо экономить_ им недоступно от слова _совсем_. А еще есть китайцы, ой...)

ИБМ пора переходить на какой то мФ аналог Oracle DB машины - взять обычные интел серверы, соединить в кластер инфинибандом, поставить туда FLASH PCI карточки, сделать софтом распределенную файловую систему, сверху VMware или что то подобное, и все это продавать в стойке как интегрированную систему. Но они таким макаром убьют свои собственные мейнфреймы, так как мощность такой системы в пересчете на 1 доллар цены получается раз в 100 (не шучу) выше чем у МФ.

[Dmitry67]

Вы не поняли. Та же самая java, работая под МФ, мистическим образом перестает жрать память!

Не пытайтесь ничего понять! Понять — не реально! И как только вы будете привлекать знания, будет осечка <...> не будет ничего получаться!
(с) Петрик

[zVlad]

Я не понял как это - Да Java жрет память как свинья помои, но это более критично на x86 и Power и менее критично на МФ.

На x86 это не проблема. Сервер с 256 гигами памяти стоит где то под $9K, я только что поставил в 2 дата центра 15 штук таких. Жрет и жрет, дадим сурку картошки, авось лопнет.

......

Купив за $9К хотя бы 15 серверов никто не будет даже задуматься о том насколько эффективно используются ресурсы. Да хоть бы вообще не использовалась что с того. На МФ, действительно память и вообще ресурсы не дешевы, но есть средства их использовать эфективно и вести контроль за этим. Поэтому на МФ каждый байт и каждый MIPS обоснованы и задействованы. В результате даже при высоких ценах на единицу ресурса с учетом отдачи МФ выгоднее чем Ваши 15 серверов. 15ть серверов - это 15 систем как минимум если эти сервера не VMWare. Каждой надо делать maintenance каждю надо патчить и как я понимаю по патчению мое настольного десктоп-а в офисе делать надо это довольно часто. Пусть даже делается это дистанционно, но вот мой desktop с 2 GB меморы это боя самая большая проблема на работе. Он не доступен очень уж часто - занимается патчиниенм сомого себя и работать на нем совершенно невожмо тогда. Я много раз рассказувал про это, никто не ответил мне ничем. А вывод то печален на самом деле: по ктрайней мере у Windows нет нормальной виртуальной памяти. Я вижу 2-3% CPU buzy и 1,83 GB used memory. Сделать что-либо при таких данных в Тask Manager невозможно, надо просто отварачиваться от компьютера и не трепать нервы. И это не у одного меня так как выясняется, это довольно общее и место. И Production система на МФ в LPAR s 1 GB memory в котором работает пусть несколько десятков пользователей, но они работают. Вот какая разница с использованием памяти на разных полатформах имеет место быть. А Вы повторяете как попугай сколько стоит 128 GB на МФ. На новых машинах что мы будем устанавливать в нотабре-декабре IBM минимум дает 32 GB. А у нас нет таких потребностей для нашего ERP класс приложения. Мы конечно отдадим всю память DB2 под буфер данных, но уже понятно что данные там будут сидеть без использования годами. Тоже и на вашим многогигабайтных севреах происходит -- данные загачиваются в память для однократного использования и потом сидят там долго-долго. Это не эффективно. И значит это дорого.

P.S. На x86 проблема во вводе-выводе, поэтому страничный обмен это дизастер, поэтому нужно много memory чтобы не было страничного обмена. Но поскольку даже с дешевой memory большие данные в эту память не поместить то запрягают много серверов и поехали, только считай успевай коней (серверa). У нас их тысячи на фирме, они миллионы стоят на самом деле. Никого это не пугает и не волнует, ведь это же единственный вариант, ничего больше нет в природе, вот у МФ то 1 GB стоит $1500, это ж если купим столько сколько у нас на северах стоит то раззоримся. А понять что у МФ со стрaничным обменом из-за нормального ввода-вывода все в порядке не хватает сахара в крови и опыта работы с МФ. Вот и весь расклад.

Сколько то лет назад щеголяли страницами в 1 МБ и более. Ма МФ это появилосьнемного позже, но появилось и используется вовся именно для Java и для БД. SSD локальную сделали именно для страничного обмена. У вас на серверах такие решения используются? Видимо нет раз вы ис кожи лезети ставите сотни GB memory большая часть которой как оперативная память (а именно так она называется на русском языке) вовсе не используется. Она используется как кэш для диском, об этом mskmel постоянно говорит. Короче это снежный ком, он катится под гору и скоро развалится.

[zVlad]

Вы не поняли. Та же самая java, работая под МФ, мистическим образом перестает жрать память!

Не пытайтесь ничего понять! Понять — не реально! И как только вы будете привлекать знания, будет осечка <...> не будет ничего получаться!
(с) Петрик

Память то она жрет как везде, но мы ей даем виртуальную память с 64 битным адресом. Столько ей не сожрать и столько физической памяти у вас все равно нет и не будет. Но на МФ сильный ввод-вывод (канальный - 8 Gbps на каждый линк и этих линков сотни на старшых моделях. У нас на малюсеньком МФ их 16 (4-x Gbps)) и поэтому все удается делать в гораздо меньшем обьеме реальной памяти. А у вас ввод-вывод херовый и вам нужна реальная память поэтому. Вот и думайте.
Страницы мы даем Java 1 MB и более, SSD локальный организовали для страничного обмена. Вот и весь секрет, никакой мистики.

[flip_flop]

Но на МФ сильный ввод-вывод (канальный - 8 Gbps на каждый линк и этих линков сотни на старшых моделях. У нас на малюсеньком МФ их 16 (4-x Gbps)) и поэтому все удается делать в гораздо меньшем обьеме реальной памяти. А у вас ввод-вывод херовый и вам нужна реальная память поэтому. Вот и думайте.

Избирательная забывчивость, опять и опять и снова. "Всё на одной верёвке, ввод-вывод херовый".

Год назад (или больше) я приводил данные для SGI-UV 300: 32 sockets, 24 TB RAM, 64 PCIe NVMe cards, 30 millions IOPS, 240 GB/s (B, not b). Для новых NVMe карточек ещё быстрее будет. Это не ввод-вывод херовый, это у кого то память херовая.

P.S, Я сейчас на десктопе (в десктопном форм факторе) могу получить IO как у вашего мейнфрейма. С гораздо лучшей латентностью, ибо локальные быстрые PCIe NVMe SSD.

[zVlad]

....

ИБМ пора переходить на какой то мФ аналог Oracle DB машины - взять обычные интел серверы, соединить в кластер инфинибандом, поставить туда FLASH PCI карточки, сделать софтом распределенную файловую систему, сверху VMware или что то подобное, и все это продавать в стойке как интегрированную систему. Но они таким макаром убьют свои собственные мейнфреймы, так как мощность такой системы в пересчете на 1 доллар цены получается раз в 100 (не шучу) выше чем у МФ.

Ну и сколько ж стоят эти Oracle DB машины? Не $9К ведь.

Можно сказать что МФ это и есть то что Вы написали. Только сервера внутри него не на Интел, а на собственных процессорах которые хотя бы тем лучше что имеют микропрограммную поддержку zOS. Есть и инфинибанд, есть и PCI карточки: Ficon, Crypto, Compression, OSA, Flash Express и т.д.
Это в Ваших серверах за $9K нет ничего кроме CPU, memory и сетевой карточки. Много CPU много memory, но мало толку в смысле полезной работы. Уверен, Вы сами толком не знаете что те 15 серверов делают полезного. У Вас попросили, Вы и дали что просили, не дорого ведь, чего жалеть то пусть подавятся, авось подохнут раньше.

[zVlad]

Но на МФ сильный ввод-вывод (канальный - 8 Gbps на каждый линк и этих линков сотни на старшых моделях. У нас на малюсеньком МФ их 16 (4-x Gbps)) и поэтому все удается делать в гораздо меньшем обьеме реальной памяти. А у вас ввод-вывод херовый и вам нужна реальная память поэтому. Вот и думайте.

Избирательная забывчивость, опять и опять и снова. "Всё на одной верёвке, ввод-вывод херовый".

Год назад (или больше) я приводил данные для SGI-UV 300: 32 sockets, 24 TB RAM, 64 PCIe NVMe cards, 30 millions IOPS, 240 GB/s (B, not b). Для новых NVMe карточек ещё быстрее будет. Это не ввод-вывод херовый, это у кого то память херовая.

P.S, Я сейчас на десктопе (в десктопном форм факторе) могу получить IO как у вашего мейнфрейма. С гораздо лучшей латентностью, ибо локальные быстрые PCIe NVMe SSD.

Если ввод-вывод такой хороший то на фига 24 TB RAM? При таком вводе-выводе все 24 TB будут заполнены за примерно 100 секунд. Что дальше будет происходить? Вывод данных обратно? За сколько времени 32 sockets потрогают все байты 24 терабайтной памяти? Что в это время будет делать ввод-вывод?
Из наших 16 Ficon4 (4Gbps) только половина к чему- нибудь подключены. Загрузки более чем на несколько процентов этих Ficon я никогда не видел. Это при 24 GB RAM, 5 CPU и все инстансес ERP класс приложения производителя электроэнергии в Онтарио.
Что те Ваши чудо машинки, о которых Вы мне несколько раз в году напоминаете, делают полезного?

[flip_flop]

Что те Ваши чудо машинки, о которых Вы мне несколько раз в году напоминаете, делают полезного?

Чудо машинки, о которых Вы постоянно "забываете", нацелены на одновременно и достаточно быстрые вычисления (HPC) и на аналитику/анализ данных/in memory database/SAP HANA. Вас не поймёшь, то хорошее IO хорошо, то плохо, потому как простаивает. Видимо хорошесть определяется принакдлежностью к МФ, а нехорошесть - к не МФ .

И как бы ни крутили с виртуальной памятью на SSD, скорость работы будет намного меньше скорости работы напрямую с памятью. Отсюда все эти in memory database вместо наращивания дисков при непропорционально лилипутской памяти. В "моём" чипе, который скоро выйдет, будет 16 GB в корпусе микросхемы, не говоря уже о внешней памяти. Новые технологии памяти раздвинут горизонты архитектур компьютеров ещё дальше. А Вы всё об экономии памяти.

Но это не главное. В данном диспуте это всего лишь напоминание для тенденционно "забывчивых" что IO на х86 серверах не такой уж херовый. Даже на моём десктопе (пусть и не типичном) IO не такой уж херовый. А, ну да, наверное херовый, раз не 100% утилизирован

[Palych]

Купив за $9К хотя бы 15 серверов никто не будет даже задуматься о том насколько эффективно используются ресурсы. Да хоть бы вообще не использовалась что с того. На МФ, действительно память и вообще ресурсы не дешевы, но есть средства их использовать эфективно и вести контроль за этим. Поэтому на МФ каждый байт и каждый MIPS обоснованы и задействованы. В результате даже при высоких ценах на единицу ресурса с учетом отдачи МФ выгоднее чем Ваши 15 серверов.

Снизить потребление памяти средствами автоматического контроля в Java можно, но не радикально.
Рано или поздно эта оптимизация упрется в качество кода. А переписывать код очень и очень дорого.
Останется только добавлять память: в сам компьютер, или "с черного хода" - в контроллеры. Не суть важно.

[flip_flop]

Это в Ваших серверах за $9K нет ничего кроме CPU, memory и сетевой карточки

В анналы, чтобы перл не пропал

[zVlad]

Купив за $9К хотя бы 15 серверов никто не будет даже задуматься о том насколько эффективно используются ресурсы. Да хоть бы вообще не использовалась что с того. На МФ, действительно память и вообще ресурсы не дешевы, но есть средства их использовать эфективно и вести контроль за этим. Поэтому на МФ каждый байт и каждый MIPS обоснованы и задействованы. В результате даже при высоких ценах на единицу ресурса с учетом отдачи МФ выгоднее чем Ваши 15 серверов.

Снизить потребление памяти средствами автоматического контроля в Java можно, но не радикально.
Рано или поздно эта оптимизация упрется в качество кода. А переписывать код очень и очень дорого.
Останется только добавлять память: в сам компьютер, или "с черного хода" - в контроллеры. Не суть важно.

Наша DB2 DBA ужасно боится страничного обмена. Я как то взял и увеличил DB2 буферные пулы и у нас появился страничный обмен и ничего страшного не произошло. В zOS есть параметр в механизме страничного обмена на основании которого можно судить насколько плох в данный момент страничный обмен. В том случае страничный обмен был далеко не так уж плох. Наша DB2 DBA уменьшила буферные пулы чтобы обмен исчез. Но наша DB2 DBA не понимает что то что происходит в буферных пулах DB2 это тоже своего рода страничный обмен только не в файлы страничного обмена, а в табличные пространств.
Я не о том чтобы снижать потребление памяти в Java, пусть себе запрашивает, давайте ей виртуальную память, материализуйте ее по мере необходимости в реальной памяти, если реальной не достаточно выбрасывайте страницы во внешнюю память (делайте только это интеллектуально и строго по мере необходимости), введите понятие рабочего набора и введите механизм ограничения набора реальных страниц для разных... не знаю, контейнеров будет ли правильно сказать, или разных программ на апликэйшн сервере в соответствии с важностью тех или иных программ. На данный момент как я понимаю Java является священной коровой и ей дают реальной памяти столько сколько запрашивается бодро бегая в ближайший компьютерный магазин за очередной горстью модулей памяти, благо что она дешевая и нам не жалко денег.

[StrangerR]

Это в Ваших серверах за $9K нет ничего кроме CPU, memory и сетевой карточки

В анналы, чтобы перл не пропал

А, ну да, нету ничего. Ну добавим еще SAN стоимостью где то $20K.

Имеем за эти деньги
- 15 серверов. На них примерно крутится 300 - 400 VM, примерно 1,000 виртуальных процессоров на них, примерно 4.5 TB оперативки в сумме.

Ввод вывод - представьте себе, на самих серверах стоят SATA (или SAS) 4 TB и SSD cache, на 480 GB у меня, причем на новых G9 можно уже делать и write cache.

На внешней стойке около 40 TB дисковой памяти раскиданной на 3 уровня автоматически - ARCHIVE (SATA 7200 k RPM), STANDARD (SAS, 10K RPM), SSD. Ну может конструкция стоила не 20 а 30K в сумме с учетом лицензий, но это максимум. И она поддерживает 10GB iSCSI x 4 MPIO (то есть очень если нужно то можно до 40 GBit разогнать). Серверы будут чуть дороже если там еще и 10GB поддерживать но не в разы.

А еще в сервер можно поставить Intel DC3700 FLASH DISK с PCI интерфейсом. Который значительно шустрее чем просто SAS или SATA. Можно много чего еще добавить.

А патчить... сами VMware патчатся - эвакуировали с них VM и запатчили, потом назад, все ONLINE. SAN патчится онлайн. Сами VM-ки теоретически естьт способы патчить снаружи хотя я их и не использую но такое бывает.

В общем, МФ тоскливо плачет в уголке глядя на все это. Особенно если не экономить как мы а взять чуть повыше в ряду ИНтелов и в ряду SAN-ов.

Да, а память которая магически не расходуется меня порадовала. Ну или да, устроим SWAP SSD CACHE. Только ведь на VMware это есть и если я это устрою, я на 256 гигов запихну не как сейчас - 300 GB vRAM, а и все 500. Сколько стоит 500 GB RAM для МФ? А если 10 по 500?

Наша DB2 DBA ужасно боится страничного обмена.

Интересно а сколько памяти ей дали? А то я недавно ораклу у девелоперов увеличивал RAM до 64 GB, а в продакшене у кастомера стоит кажется 256GB. На один сервер баз данных. У меня в продакшене в одном из проектов стоит кажется 80 но там довольно старый сервер, а то сделали бы и 192GB.

Я не о том чтобы снижать потребление памяти в Java, пусть себе запрашивает, давайте ей виртуальную память, материализуйте ее по мере необходимости в реальной памяти, если реальной не достаточно выбрасывайте страницы во внешнюю память (делайте только это интеллектуально и строго по мере необходимости), введите понятие рабочего набора и введите механизм ограничения набора реальных страниц для разных... не знаю, контейнеров будет ли правильно сказать, или разных программ на апликэйшн сервере в соответствии с важностью тех или иных программ.

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

Но это не главное. В данном диспуте это всего лишь напоминание для тенденционно "забывчивых" что IO на х86 серверах не такой уж херовый.

Я уже написал. Нужно много много IO? Поставьте Intel PCI SSD DC3700 - и будет у вас IO до горизонта. НО и без этого там неплохо и новые серверы умеют делать на SSD и своего рода кэш и на чтение и более новые на запись, что снимает проблему (SSD дорого а SATA медленно). Ну и все таки 15 серверов - суммарный IO рекомендуется умножить на 15 (понятно что иногда нужен единичный но для этого и есть PCI SSD, 256 GB RAM и прочие вкусности).

[Dmitry67]

Даже на моём десктопе (пусть и не типичном) IO не такой уж херовый. А, ну да, наверное херовый, раз не 100% утилизирован

Конечно, нормальный IO должен быть на 100% утилизирован страничным обменом, память то дорогая )))

[Dmitry67]

Нужно много много IO? Поставьте Intel PCI SSD DC3700 - и будет у вас IO до горизонта. НО и без этого там неплохо и новые серверы умеют делать на SSD и своего рода кэш и на чтение и более новые на запись, что снимает проблему (SSD дорого а SATA медленно). Ну и все таки 15 серверов - суммарный IO рекомендуется умножить на 15 (понятно что иногда нужен единичный но для этого и есть PCI SSD, 256 GB RAM и прочие вкусности).

На запись?
Я смотрел Virtual SAN от VMware, там было только про чтение
Расскажите что знаете плиз... Может ли это уменьшить write latency, что важно для баз.
Правда думаю у нас NetApp навсегда... Так сложилось )))
Впрочем даже pure-SSD netApp RAID 10 давал write latency 0.6ms. Локальный SSD рвет его как тузик грелку...

[StrangerR]

Нужно много много IO? Поставьте Intel PCI SSD DC3700 - и будет у вас IO до горизонта. НО и без этого там неплохо и новые серверы умеют делать на SSD и своего рода кэш и на чтение и более новые на запись, что снимает проблему (SSD дорого а SATA медленно). Ну и все таки 15 серверов - суммарный IO рекомендуется умножить на 15 (понятно что иногда нужен единичный но для этого и есть PCI SSD, 256 GB RAM и прочие вкусности).

На запись?
Я смотрел Virtual SAN от VMware, там было только про чтение
Расскажите что знаете плиз... Может ли это уменьшить write latency, что важно для баз.
Правда думаю у нас NetApp навсегда... Так сложилось )))
Впрочем даже pure-SSD netApp RAID 10 давал write latency 0.6ms. Локальный SSD рвет его как тузик грелку...

HP G8 - при установке лицензии и наличии SSD диска можно включить SSD based read cache. Нужна лицензия ($300) и кэш память 1 или 2 гига (на 512 не работает).

HP G9 - тоже самое но SSD write cache уже может быть. Правда, я не очень понимаю как это там сделано, потому что если для RO cache raid не нужен (ну полетит так полетит, данные то есть на дисках) то для RW кэша по идее уже нужен RAID.

В VMware рулится через esxcli hpa-что-то там cmd -q "команда" , найдете (esxcli даст список что там есть, hpa-что-то там увидите запустите он скажет какие опции есть, и так далее)

(Я сделал password less ssh в ESXi так как все ихние API оказались весьма убогими хотя инвентори через них получилось. И в итоге куча всего делается из центра не через VC а просто вызывая ssh)

// У меня еще остались старые нетаппы, штука неплохая но цена/емкость проигрывает, тем паче проекты хотят по 10 - 20 TB каждый а то и больше... С другой стороны, возможноч то SSD netapp + dedup должны дать неплохие результаты. А ккстати ну латенси и латенси, за редким исключением оно никому особо не мешает, исключение пожалуй гол файлы базы данных.

[flip_flop]

Поставьте Intel PCI SSD DC3700 - и будет у вас IO до горизонта.

Уже появились новые P3608 - до 5 GB/s для чтения на одну карточку вместо 3-х.

[zVlad]

....

А, ну да, нету ничего. Ну добавим еще SAN стоимостью где то $20K.
.....

Опять тоже самое: можно добавить, можно поставить, 4 TB SATA, 300-400 виртуальных машин. Я задал простой вопрос: что все это чудо современной ИТ делает не для самого себя а для людей? Как называется не в параметрах IT работа этого чуда? Насколько оно все загружено: CPU utilization, memory, диски, чем они загружены? Порнографией или файлами стаховщиков в ииншуренской компании? Каков средний размер файла (пусть даже с фотографиями застрахованных)? Сколько застрахованных? Сколько в общем транзакцуй в день в этой страховой компании на их IT происходит?
Надеюсь теперь понятно о чем спрашивается? Про то что делается на нашем МФ я уже много раз рассказывал: он (один) для ERP приложения (work orders, equipment, warehouse, и т.д. и т.п. кроме финансов и HR), причем все instances: QA, DEV (поставляется софт извне, но кое-что подкудрявливают наши 2.5 + работа с данными), Sandbox-ы и Training + разное по мелочам. Могу также сказать что в пиковые часы CPU (все 5(пять)100% buzy (в Production который имеет ровно 85% от всего МФ), memory используется на 100% и есть небольшой страничный обмен, каналы загружены незначительно. В системе идет сбор всей статистики и клиенту предоставляется SLA отчет по общей работе и по ризмерениям производимым роботами, которые с каждой location клиента по времени запускают тестовые транзакции и измеряют время ответа.

У нас нет ни одной виртуальной машины (нет zVM), все происходит в двух LPAR. И на одном МФ крутятся все базы данных прилохения и апликэйшн сервера (CICS).

Вы для чего приводите все Ваши числа? Чтобы поразить мое воображение? Хорошо поразили, теперь расскажите о полезной работе выполняемой на Вашем IT инфраструктуре. В пнятных любому человеку терминаx. Сколько дров нарублено, сколько ведер воды принесено и булок хлеба испечено. А то что можно до изумления считать нули в памяти компьютера это я и без Вас знаю. А я Вам в дополнению к уже сказанному скажу сколько мегават энергии наши станции вырaбатывают в год, сколько домов питается этой энергией и сколько бизнесов работает, а также и сколько миллиардов долларов за эту энергию наш клиент получает.

[oshibka_residenta]

Вы для чего приводите все Ваши числа? Чтобы поразить мое воображение? Хорошо поразили, теперь расскажите о полезной работе выполняемой на Вашем IT инфраструктуре. В пнятных любому человеку терминаx. Сколько дров нарублено, сколько ведер воды принесено и булок хлеба испечено. А то что можно до изумления считать нули в памяти компьютера это я и без Вас знаю. А я Вам в дополнению к уже сказанному скажу сколько мегават энергии наши станции вырaбатывают в год, сколько домов питается этой энергией и сколько бизнесов работает, а также и сколько миллиардов долларов за эту энергию наш клиент получает.

А что это докажет?
Вот, к примеру, пробили скважены в земле и из скважен течет нефть на сотни миллионов долларов. Никаких компьютеров нет, кроме китайского калькулятора в кармане бригадира. Вывод: калькулятор в 100 раз полезнее IBM mainframe.

[flip_flop]

Вы для чего приводите все Ваши числа? Чтобы поразить мое воображение? Хорошо поразили, теперь расскажите о полезной работе выполняемой на Вашем IT инфраструктуре. В пнятных любому человеку терминаx. Сколько дров нарублено, сколько ведер воды принесено и булок хлеба испечено. А то что можно до изумления считать нули в памяти компьютера это я и без Вас знаю. А я Вам в дополнению к уже сказанному скажу сколько мегават энергии наши станции вырaбатывают в год, сколько домов питается этой энергией и сколько бизнесов работает, а также и сколько миллиардов долларов за эту энергию наш клиент получает.

А что это докажет?
Вот, к примеру, пробили скважены в земле и из скважен течет нефть на сотни миллионов долларов. Никаких компьютеров нет, кроме китайского калькулятора в кармане бригадира. Вывод: калькулятор в 100 раз полезнее IBM mainframe.

Ха, до того как бить скважины, было проведена сейсмологическое моделирование и много ещё других вычислений для разведки нефти. Классическое приложение HPC. MF правда там нет, совсем нет, кластеры Xeon с большим числом узлов, процессоров и огромным объёмом памяти, что так не любо апологетам МФ. Из области ИТ там идёт производительная аналитика на больших данных, данных в памяти. МФ тоже нет там, от слова совсем.

[zVlad]

Вы для чего приводите все Ваши числа? Чтобы поразить мое воображение? Хорошо поразили, теперь расскажите о полезной работе выполняемой на Вашем IT инфраструктуре. В пнятных любому человеку терминаx. Сколько дров нарублено, сколько ведер воды принесено и булок хлеба испечено. А то что можно до изумления считать нули в памяти компьютера это я и без Вас знаю. А я Вам в дополнению к уже сказанному скажу сколько мегават энергии наши станции вырaбатывают в год, сколько домов питается этой энергией и сколько бизнесов работает, а также и сколько миллиардов долларов за эту энергию наш клиент получает.

А что это докажет?
Вот, к примеру, пробили скважены в земле и из скважен течет нефть на сотни миллионов долларов. Никаких компьютеров нет, кроме китайского калькулятора в кармане бригадира. Вывод: калькулятор в 100 раз полезнее IBM mainframe.

Мы на уровне участников форума и их областей деятельности не можем разобраться, а Вы сразу в глобальном масштабе начинаете.

[zVlad]

Нужно много много IO? Поставьте Intel PCI SSD DC3700 - и будет у вас IO до горизонта. НО и без этого там неплохо и новые серверы умеют делать на SSD и своего рода кэш и на чтение и более новые на запись, что снимает проблему (SSD дорого а SATA медленно). Ну и все таки 15 серверов - суммарный IO рекомендуется умножить на 15 (понятно что иногда нужен единичный но для этого и есть PCI SSD, 256 GB RAM и прочие вкусности).

На запись?
Я смотрел Virtual SAN от VMware, там было только про чтение
Расскажите что знаете плиз... Может ли это уменьшить write latency, что важно для баз.
Правда думаю у нас NetApp навсегда... Так сложилось )))
Впрочем даже pure-SSD netApp RAID 10 давал write latency 0.6ms. Локальный SSD рвет его как тузик грелку...

Уже давно используется в дисках для МФ. Называется non-volatile. Даже в тех старых дисках в том старом тесте который мы с mskmel анализируем в теме "IBM PC" была такая память:

The Model 800 had 16 GB regular cache and 2 GB non-volatile storage (NVS)

Запись на диски с таким кэшем происходит за время образщия к памяти (через канал естественно), а потом уже дисковая подсистема переписывает данные в persistent storage. Гарантируется что при выключении питания данные не пропадут, а будут дописаны куда надо.

[Palych]

Я не о том чтобы снижать потребление памяти в Java, пусть себе запрашивает, давайте ей виртуальную память, материализуйте ее по мере необходимости в реальной памяти, если реальной не достаточно выбрасывайте страницы во внешнюю память (делайте только это интеллектуально и строго по мере необходимости), введите понятие рабочего набора и введите механизм ограничения набора реальных страниц для разных... не знаю, контейнеров будет ли правильно сказать, или разных программ на апликэйшн сервере в соответствии с важностью тех или иных программ.

Вы этот подход пробовали на реальном приложении?
Экстраполяция опыта DB2 тут не уместна: память расходуется совершенно по-разному.
К тому же мне интересно как бы Вы определили важность того или иного компонента в он-лайновом приложении.
А главное - гуд лак, как говориться в выделение тех контейнеров и прочего внутри Java Heap.