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

[zVlad]

...

Нашел ещё крохи инфы по conversion factor.
https://www.ibm.com/developerworks/comm ... _a?lang=en" onclick="window.open(this.href);return false;

Sun Fire X2100 M2, model 1220 server (2-way)
IBM did not pick a wimpy machine to compare against. The model 1220 is the fastest in the series, with a 2.8Ghz x86-64 dual-core AMD Opteron processor
...
I have reverse-engineered a new z10-to-Opteron conversion factor as 6.866 z10 EC MIPS per GHz of dual-core AMD Opteron for I/O-intensive workloads running only 10 percent average CPU utilization. Business applications that perform a lot of I/O don't use their CPU as much as other workloads.For compute-intensive or memory-intensive workloads, the conversion factor may be quite different, like 200 MIPS per GHz, as Jeff Savit from Sun Microsystems points out in the comments below.

Уберем IO bound приложения, т.к. сервера приложений к ним как правило не относятся.
Статья 2008го года, приведем к некой легко используемой единице: 4ре ядра они оценивают в 200MIPS per GHz или 50MIPS per GHz на ядро.

Достаточно популярны сейчас 2 сокета, 18 ядер по 2.3ГГц, или 2*18*2.3=82.3ГГц, чтобы поменять один такой сервер надо на 7% больше чем 4140MIPS или 4430MIPS, они исходят из 90% утилизации 4922MIPS.

....

Хорошо что Вы хоть что-то находите и читаете о МФ, другие просто откуда-то говорят даже не делая попыток узнать. Плохо только то что Вы читаете найденное не полностью и выводы делаете не корректно. Я Вам помогу.

Сервера приложений не настолько IO bound насколько сервера БД, но они и не CPU bound тоже. Не упускайте из виду операции с сетевыми картами. Это тоже своего рода ввод-вывод.

Если сравнивать яблоки с яблоками то убирать IO bound приложения нельзя. Потому что на МФ не выполняется один какой нибудь класс приложений. На МФ всегда выполняется микс из разных приложений, и IO bound, CPU bound и промежуточные.

Жонглирование с GHz и MIPS я не очень понимаю, но пусть будет так как делает автор блога приведенного Вами. Но вот использование чисел полученных в 2008 году в жонглировании с "популярными сейчас" серверами и вычислением MIPS для совершенно не обоснованно. Обоснованные числа для этого могли бы быть получены только через повторение "реверс-инжиниринга" автора блога.

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

Читать надо было все, mskmel. Тогда бы Вам не пришло в голову сравнивать яблоки с апельсинами неверно используя приведенные числа.

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

[zVlad]

....

Скорее всего CPU будет максимум 80% buzy в пиковые часы, но ночью что 1000 MIPS, что 2000 MIPS будут простаивать в основном. Есть смысл ? Нет никакого смысла в увеличении мощности нашего МФ в наших условиях.

Ваш МФ это 1000MIPS, т.е. примерно 20-25% загрузки современного самого "ходового" 2х сокетника. Стоит он меньше ~15-18к для 384ГБ памяти.
Сколько стоит сейчас МФ с 4-5кMIPS\256-384ГБ? В 2008Q1 это было 3.8mln-4.5mln

MIPS это миллион операций в секунду. Машинных команд (инструкций) иными словами. MIPS это единица можности CPU, а не МФ в целом. ИБМ официально не поддерживает эту единицу измерения. Официальной единицей (также принятой в WLM) является SU/s - service units per seсond. Углубляться пока не будем.

Я отвечу на Ваш вопрос несколько необычным способом. Вы видимо не читали мои рассказы об одном нашем кастомере ушедшем с МФ лет пять назад. Эти рассказы были с приведением реальных чисел как по МФ так и по RICS серверам на которые они перешли (именна серверах во множественном числе и МФ в единственном. Числа я давал и по количеству CPU на МФ (там их было всего два, и они делились с девелормент LPAR другого нашего кастомера, Production которого сейчас стоит на 1000 MIPS и они делятся опять же с девелопмент LPAR но уже одного и того же кастомера) и по памяти, которой было... наверное пару гигов. И приводил числа по RISC серверам в которых были десятки ядер и сотни гигов памяти. Вы можете легко найти те числа здесь на форуме в "Вопросах ИТ". Это реальный случай который я мог отслеживать. Да и еще скажу кастомер ушедший от нас на RISC имел объемы нагрузки в несколько раз меньшие чем тот что сейчас крутить все на одном МФ с 1000 MIPS.

В этот выходной мы клонировали систему с приложением, которое до сих пор использовалось этими кастомерам. Речь идет о МФ c 73 MIPS (z10 BC A03: http://www.tech-news.com/publib/pl2098.html" onclick="window.open(this.href);return false; ). До вчерашнего дня на этом МФ было 4 LPAR: совместные Production и Development, LPAR с программой (CA ESP: http://www.ca.com/ca/en/opscenter/ca-wo ... ition.aspx" onclick="window.open(this.href);return false; ), которая "provides a single point of control to define, monitor and manage scheduled and event-based workloads across all enterprise applications and platforms." Именно во всей нашей enterprise, не только не только на МФ, но исключая МФ поскольку на других система МФ есть свои ESP экземпляры. Это конечно не весть какая нагрузка но и 73 MIPS не всеть какая мощность. В четвертом LPAR стоит мой sandbox на котором я делаю проверки новый версий zOS, патчей и вообще разных идей и проектов. Все 4 LPAR вместе занимали 6 GB, и 6GB было не распределенных.

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

[mskmel]

Сервера приложений не настолько IO bound насколько сервера БД, но они и не CPU bound тоже. Не упускайте из виду операции с сетевыми картами. Это тоже своего рода ввод-вывод.
...
Если сравнивать яблоки с яблоками то убирать IO bound приложения нельзя.

"Живая" нагрузка на х64 в виде
~40Гб\сек storage, ~30-40kIOPS
~4-8Гб\сек network, application usage
~20-60Гб\сек inter cluster communication
всё это вместе едва "грузит" 1-4 ядра Xeon, коих всего за $100к напихивается аж 120. CPU System time при таких нагрузках можно принебречь.
Так что выделенные процессоры МФ для IO это круто, но это big band aid уже давно не применяющийся в параллельном мире. "Карты шифрования" ушли в историю с Intel AES

Сервера БД легко становятся не IO bound при наличии достаточного количества памяти. Упомянутые выше буфера в несколько ГБ на упреждающее чтение это ничто, они "съедаются" за пару секунд при последовательном доступе и неэффективны при случайном... и опять ждем пока там диски что-то отдадут, пусть из своего убогого кэша.

И уже не в первый раз: данные, лежащие "близко" к процессору в памяти существенно экономят денежку. Кэшированные данные на сервере приложений это существенное снижение нагрузки на БД, снижение затрат на лицензии БД, cнижение затрат на систему хранения для БД (СХД досихпор стоят дорого). Именно процессорами накормили БД уже давно, главная битва идёта за обработку данных в памяти: Oracle In-Memory Database, Oracle Coherence, Apache Spark и просто кэширование в достаточном объёме любыми доступными способами. На одном из прошлых проектов поднятие кэширования в БД с 120ГБ до 300ГБ уменьшило нагрузку на систему хранения почти на порядок при нулевом вмешательстве в приложение (нет затрат на разработчиков, которые стоят по 150к+ в год штука), это много-много денег сэкономлено, при относительно нелевых инвестициях. Но 300-500ГБ под одну задачу на МФ кажется какими-то космичскими технологиями c космическими затратами.

Я не просто переключил область задач на сервера приложений, потому как это достаточно предсказуемый и платформанезависимый класс задач. Именно они, а не БД, "жрут" бОльшее количество железа.

[zVlad]

Можно я Вас поспрашиваю как специалиста по серверам приложений.

Сервера приложений берут данные от серверов БД? Или нет. Как эти данные поступают на сервера приложений? По какому интерфэйсу?

В сервере приложений "крутятся" многие пользовательские процесссы. У каждого своя память. Знает ли один процесс что нужные ему данные имеются в памяти другого процесса? Может ли он к этим данным обратиться или он получает свою копию этих данных?

[iDesperado]

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

[Dmitry67]

Оптимизации в духе криптопроцессора на МФ мне напоминают одну вещь
Я приведу цитаты, а вы вспомните, откуда это:

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

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

Разрезав пришедший в негодность детский резиновый мяч на две неравные части, вложите меньшую часть в большую… безотказно действующее приспособление для прочистки засорившейся раковины умывальника - готово!

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

[flip_flop]

Советы мастеру. Маленькие хитрости. Наука и жизнь.

[Dmitry67]

Бинго !

[mskmel]

Сервера приложений берут данные от серверов БД? Или нет. Как эти данные поступают на сервера приложений? По какому интерфэйсу?

Ethernet\IP\jdbc

В сервере приложений "крутятся" многие пользовательские процесссы. У каждого своя память.

Тут схема работы сложнее. Помимо пользовательских процессов, есть процессы сервера приложений в том числе и для кэширования. Пользовательские процессы могут брать данные из кэша, если разработчики его имплементировали.
Есть ли общение между самими серверами приложений - зависит от реализации. Например Oracle Coherence это грубо программная инфраструктура для хранения\кэширования данных на уровне серверов приложений.

ЗЫЖ я не специалист по серверам приложений, но в силу любознательности пытаюсь понять как это всё работает.

[zVlad]

Сервера приложений берут данные от серверов БД? Или нет. Как эти данные поступают на сервера приложений? По какому интерфэйсу?

Ethernet\IP\jdbc

В сервере приложений "крутятся" многие пользовательские процесссы. У каждого своя память.

Тут схема работы сложнее. Помимо пользовательских процессов, есть процессы сервера приложений в том числе и для кэширования. Пользовательские процессы могут брать данные из кэша, если разработчики его имплементировали.
Есть ли общение между самими серверами приложений - зависит от реализации. Например Oracle Coherence это грубо программная инфраструктура для хранения\кэширования данных на уровне серверов приложений.

ЗЫЖ я не специалист по серверам приложений, но в силу любознательности пытаюсь понять как это всё работает.

Я тоже пытаюсь понять и то что говорят другие (hibernate) и Вы (Oracle Coherence) пока навевают мне грусть.

Я обдумаю это и почитаю потом скажу. Пока рекомендую почитать вот эту техническую статью:

https://www-03.ibm.com/support/techdocs ... x/WP101476" onclick="window.open(this.href);return false;

[Palych]

Тут схема работы сложнее. Помимо пользовательских процессов, есть процессы сервера приложений в том числе и для кэширования. Пользовательские процессы могут брать данные из кэша, если разработчики его имплементировали.
Есть ли общение между самими серверами приложений - зависит от реализации. Например Oracle Coherence это грубо программная инфраструктура для хранения\кэширования данных на уровне серверов приложений.

ЗЫЖ я не специалист по серверам приложений, но в силу любознательности пытаюсь понять как это всё работает.

Я тоже пытаюсь понять и то что говорят другие (hibernate) и Вы (Oracle Coherence) пока навевают мне грусть.

Никаких "пользовательских процессов" в app servers нет. Это один процесс.
То же с "пользовательской памятью": отчасти к этому можно отнести Sessions, но их вообще-то лучше избегать по возможности.
По поводу грусти - очень верно.
Я даже опасаюсь за zVlad - мне кажется когда он поймет как устроены современные приложения крутящиеся в app servers у него может случиться глубокая депрессия...

[zVlad]

Тут схема работы сложнее. Помимо пользовательских процессов, есть процессы сервера приложений в том числе и для кэширования. Пользовательские процессы могут брать данные из кэша, если разработчики его имплементировали.
Есть ли общение между самими серверами приложений - зависит от реализации. Например Oracle Coherence это грубо программная инфраструктура для хранения\кэширования данных на уровне серверов приложений.

ЗЫЖ я не специалист по серверам приложений, но в силу любознательности пытаюсь понять как это всё работает.

Я тоже пытаюсь понять и то что говорят другие (hibernate) и Вы (Oracle Coherence) пока навевают мне грусть.

Никаких "пользовательских процессов" в app servers нет. Это один процесс.
То же с "пользовательской памятью": отчасти к этому можно отнести Sessions, но их вообще-то лучше избегать по возможности.
По поводу грусти - очень верно.
Я даже опасаюсь за zVlad - мне кажется когда он поймет как устроены современные приложения крутящиеся в app servers у него может случиться глубокая депрессия...

А вот по этому поводу за меня волноваться точно не надо. И вряд ли мне понадобится понимать как " устроены современные приложения крутящиеся в app servers " если мне удастся убедить вернуть WebSphere в zOS туда где ранится DB2. В этом случае источник данных (DB2) и потребитель "процесс" или "sessions" окажутся в одном и том же пространсве памяти и им будет гораздо проще управлять данными.

Как известно БД помещают данные удовлетворяющие запросам в память (buffer pools в случае DB2). Если эти данные запрошенны из вне системы где БД сидит то их надо передать через каналы связи либо непосредственно тому кто запросил либо через неого посредника. Но данные в буффер поолс доступны уже не только тому кто их запрашивал, но вообще всем другим запросам тоже. T.e. DB2 уже делает то о чем говорит iDesperado:

апп сервера обычно работают с базами данных через ORM библиотеки, например java сервера через hibernate. "пользовательские процессы" обращаются к hibernate, hibernate имеет свой кеш и сначала смотрит там и обращается к базе данных только в случае если данных нет в кеше hibernate

... и mskmel:

Помимо пользовательских процессов, есть процессы сервера приложений в том числе и для кэширования. Пользовательские процессы могут брать данные из кэша, если разработчики его имплементировали.
Есть ли общение между самими серверами приложений - зависит от реализации. Например Oracle Coherence это грубо программная инфраструктура для хранения\кэширования данных на уровне серверов приложений.

Вот толькo никаких "кешей hibernate " в случае co-lacation не нужно. Эту функцию естественным образом выполняет сама DB2, которая лучше любого hibernate/Oracle Coherence знает какие данные нужно иметь в buffer pools, а какие нет. Это уже не говоря о том что пути в рамках одной памяти гораздо короче чем пути между паматью разных северов пусть даже связанных суперскоростными каналами.

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

Спасибо, ребята, вы меня успокоили. Теперь я имею еще один козырь в пользу МФ. Не в игре с вами, а в проведении своей линии в нашей компании. В статье "The value of co-location.." об этом говорится вскользь, нет сравнения с методами используемые на других платформах, все этими "hibernate", и "Oracle Coherence". Нет, я конечно углублюсь в эти механизмы, чтобы точнее понять силу DB2 и co-location.

[Dmitry67]

Я бы не было бы столь категоричным
Например, IIS для каждого pool держит отдельный процесс
Конечно внутри каждого процесса куча threads

[Easbayguy]

Сервера БД легко становятся не IO bound при наличии достаточного количества памяти. Упомянутые выше буфера в несколько ГБ на упреждающее чтение это ничто, они "съедаются" за пару секунд при последовательном доступе и неэффективны при случайном... и опять ждем пока там диски что-то отдадут, пусть из своего убогого кэша.

Не факт, у меня скажем на 100ТБ базе, увеличение buffer cache с 100GB до 300GB снизило количество физических обращений на 30%-40%, то есть не на порядок. Но это при до 100,000 одновременных пользователей.

[Dmitry67]

Влад, какой еще козырь? В том, что DB2 использует buffer pool? Так он у всех есть. Просто в 3tier добавляется еще один уровень кэширования. Так что все также. Ах да, разница есть, buffer pool в DB2 крошечный

[mskmel]

Не факт, у меня скажем на 100ТБ базе, увеличение buffer cache с 100GB до 300GB снизило количество физических обращений на 30%-40%, то есть не на порядок. Но это при до 100,000 одновременных пользователей.

Не понял что "не факт"

30-40% это плохо? Попробуй увеличить buffer cache на порядок, и смотри получиться ли уменьшить IO на порядок Сделали бы они у advisor больше диапазон...

А еще лучше попробуй уменьши до 8ГБ как на МФ

[Easbayguy]

Не факт, у меня скажем на 100ТБ базе, увеличение buffer cache с 100GB до 300GB снизило количество физических обращений на 30%-40%, то есть не на порядок. Но это при до 100,000 одновременных пользователей.

Не понял что "не факт"

30-40% это плохо? Попробуй увеличить buffer cache на порядок, и смотри получиться ли уменьшить IO на порядок Сделали бы они у advisor больше диапазон...

А еще лучше попробуй уменьши до 8ГБ как на МФ

Если б только они слушали IBM!

[Dmitry67]

А какой порядок величины кеша на МФ?

[Palych]

Вот толькo никаких "кешей hibernate " в случае co-lacation не нужно. Эту функцию естественным образом выполняет сама DB2, которая лучше любого hibernate/Oracle Coherence знает какие данные нужно иметь в buffer pools, а какие нет.

Надо, не надо - не Вам решать.
Из написанного приложения hibernate не выкинешь.
А современные девелоперы уверены что без ORM работать с базами данных в принципе невозможно.
А кеши, насколько я слышал, там по умолчанию включены.
Так что - будьте добры предоставить память и для DB и для приложения.

[zVlad]

Вот толькo никаких "кешей hibernate " в случае co-lacation не нужно. Эту функцию естественным образом выполняет сама DB2, которая лучше любого hibernate/Oracle Coherence знает какие данные нужно иметь в buffer pools, а какие нет.

Надо, не надо - не Вам решать.
Из написанного приложения hibernate не выкинешь.
А современные девелоперы уверены что без ORM работать с базами данных в принципе невозможно.
А кеши, насколько я слышал, там по умолчанию включены.
Так что - будьте добры предоставить память и для DB и для приложения.

Я устанавливал это приложение на МФ и оно работало без hibernate о которoм я узнал только сегодня. Good enough, как говорится.

[mskmel]

Это уже не говоря о том что пути в рамках одной памяти гораздо короче чем пути между паматью разных северов пусть даже связанных суперскоростными каналами.

Во-первых у ДБ2 на МФ кэша почти нет, у вас там всего памяти несколько ГБ. Т.е. почти за каждой строчкой надо идти на диск. Для небольшого количества малокативных пользователей это будет работать.
Во-вторых, если бы и кэша было достаточно, то серверу приложений лучше взять данные у самого себя, в рамках одной jvm нежели каждый раз спрашивать у DB2.

Ладно, мы проигнорировали 1 и 2, дали много памяти ДБ2, смирились с потерями на комуникацию сервер приложений и сервер БД, смирились с достаточно низким потолком масштабирования БД. Даже переписали приложения, которые исправно трудились на х64.

И все это ради того, чтобы переложить нагрузку на БД, т.е. платить дорогие лицензии за БД, вместо сравнительно дешевых weblogic\websphere и относительно бесплатных альтернатив. В чем профит?

Hint: Для SAP benchmark, при наличии серверов приложений, для БД надо в 6 раз меньше ядер, чтобы поддерживать тоже количество пользователей.

[Dmitry67]

Разве бывают сервера (не виртуалки, а physical boxes) с памятью меньше 100 гиг? Я таких не видел...

У нас у бокса 192 гига и это рядовой член фермы, коих десятки

[Palych]

Я устанавливал это приложение на МФ и оно работало без hibernate о которoм я узнал только сегодня. Good enough, как говорится.

Кстати, можно спросить по поводу установки на МФ?
Вы смогли определить сколько памяти потребляет это приложение?
Вы его просто поставили и снести, или какие-нибудь нагрузочные тесты гоняли?

[zVlad]

Я устанавливал это приложение на МФ и оно работало без hibernate о которoм я узнал только сегодня. Good enough, как говорится.

Кстати, можно спросить по поводу установки на МФ?
Вы смогли определить сколько памяти потребляет это приложение?
Вы его просто поставили и снести, или какие-нибудь нагрузочные тесты гоняли?

Нагрузочные тесты не гоняли. Самому мне это не надо, а те кто мог бы заинтересоваться предпочел уйти в молчанку. Сколько я не привлекал внимание чтобы хотя бы посмотрели установленное приложение - ноль эмоций. Приложение было установленно на AIX спустя пару месяцев. Решение было принято "политическое". Проблемы с производительностью на AIX имеются хотя юзерс коммюнити пока еще незначительно, да и то расползается на предыдущее приложение функционально равное.
более того я имел возможность заниматься этим только два месяца - столько ИБМ дали нам бесплатно использовать один zIIP. Влияние zIIP я за это время прочуствовал хорошо. С тех пор даже не подхожу к WebSphere поскольку zIIP у нас нет. На новой машине будет - займемся снова. А пока буду разогреваться с WebSphere на Линукс.

P.S. приложение было установленно (deployed) и была проверена функциональность только. Для WebSphere использовалась все таже Development LPAR в которой у нас происходит все кроме продакшн, и обе они сидят на одном и том же МФ с пятью CPU + zIIP когда велись работы на WebSphere, и 24 GB памяти. Новый МФ будет иметь 32GB и постоянный zIIP.

[zVlad]

Это уже не говоря о том что пути в рамках одной памяти гораздо короче чем пути между паматью разных северов пусть даже связанных суперскоростными каналами.

Во-первых у ДБ2 на МФ кэша почти нет, у вас там всего памяти несколько ГБ. Т.е. почти за каждой строчкой надо идти на диск. Для небольшого количества малокативных пользователей это будет работать.
Во-вторых, если бы и кэша было достаточно, то серверу приложений лучше взять данные у самого себя, в рамках одной jvm нежели каждый раз спрашивать у DB2.

Ладно, мы проигнорировали 1 и 2, дали много памяти ДБ2, смирились с потерями на комуникацию сервер приложений и сервер БД, смирились с достаточно низким потолком масштабирования БД. Даже переписали приложения, которые исправно трудились на х64.

И все это ради того, чтобы переложить нагрузку на БД, т.е. платить дорогие лицензии за БД, вместо сравнительно дешевых weblogic\websphere и относительно бесплатных альтернатив. В чем профит?

Hint: Для SAP benchmark, при наличии серверов приложений, для БД надо в 6 раз меньше ядер, чтобы поддерживать тоже количество пользователей.

Мы не используем такого понятия кэш. Кэш, разных уровней, определен в составе CPU и есть в дисковой подсистеме. DB2 использует память организованную в buffer poos. Buffer pools представленны так называемыми data space или могут размещаться в памяти DB engine. В условиях 64 бит адресации ограничением является только ограничение физической памяти.

Вы упорно не замечаете идею co-location. Я прекрасно понимаю как это происходит. Вас долго тренировали в определенном направлении, на определенном упражнении и Вы не может воспринимать ничего отличного от натренированного. Это довольно общее место в ИТ нынче.