Демократизация мейнфреймов

[zVlad]

160 логических процессора (по два на корову, всего 80 коров) .

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

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

Тогда весь смысл виртуализании и консолидации, заключающийся в совместном использовании всех ресурсов сервера, изчезает и остаются только накладные расходы на виртуализацию и безопасность выполнения многих системных имиджей на одном сервере (or blade), вытекающая из банальной недоработки в этом плане тех систем, которые Вы гоняете на ВМ. Если последнее не так и системы Ваши надежны под любой нагрузкой, то Вы должны были бы в состоянии всю нагрузку запихать в одну систему (или несколько систем, не сотни) и не заморачиваться с виртуализацией.

[Palych]

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

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

Тогда весь смысл виртуализании и консолидации, заключающийся в совместном использовании всех ресурсов сервера, изчезает и остаются только накладные расходы на виртуализацию и безопасность выполнения многих системных имиджей на одном сервере (or blade), вытекающая из банальной недоработки в этом плане тех систем, которые Вы гоняете на ВМ. Если последнее не так и системы Ваши надежны под любой нагрузкой, то Вы должны были бы в состоянии всю нагрузку запихать в одну систему (или несколько систем, не сотни) и не заморачиваться с виртуализацией.

Если система выделена для девелопмента, то параметры её производительности одни, а когда тот же инстанс используется для отладки производительности - другие. "И никакие лекции этому не помогут".
Конечно к МФ это не относится. Там всё будет работать в любом случае.

[zVlad]

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

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

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

Если система выделена для девелопмента, то параметры её производительности одни, а когда тот же инстанс используется для отладки производительности - другие. "И никакие лекции этому не помогут".
Конечно к МФ это не относится. Там всё будет работать в любом случае.

Я не совсем об этом, если Вы заметили.
По терминалогии. У приложений нет производительности, приложения - это потребители, пассивные элементы процесса. Производительнозтью обладают компютеры, и их производительностью надо уметь граммотно распоряжаться. Когда Интел сервера были слабые и на них ставили по одному сервису на каждый этой проблемы не было. Но с ростом производительности серверов эта проблема становится все более насущной и вы (те кто в лодке Интел серверов главным образом) демонстрируете эту насущость здесь все больше и больше. Еще года три назад таких тендеций в наших дискуссиях не наблюдалось, а сейчас они явно есть.

[crypto5]

160 логических процессора (по два на корову, всего 80 коров) .

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

Предположение про МФ не верно в корне. на zOS с WLM (а без него не бывает) можно гарантировать качество сервеса по требуемому параметру - респонс тайм и т.п.

Как уже говорилось при условии если wlm знает как померять response time у приложения.

[zVlad]

160 логических процессора (по два на корову, всего 80 коров) .

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

Предположение про МФ не верно в корне. на зОС с ШЛМ (а без него не бывает) можно гарантировать качество сервеса по требуемому параметру - респонс тайм и т.п.

Как уже говорилось при условии если WLM знает как померять респонсе тиме у приложения.

На самом деле не у приложения, а у трансакции - у приложения нет респонсе тайм.

Естественно WLM может управлять и управляет только тем что может измерять. Респонсе тайм один из таких параметров. Другим похожим является цреднее значение респонсе тайм. Есть и другие параметры которые измеряет и которыми может управлять WLM.

[Dmitry67]

Как это у приложения нет response time?

[crypto5]

Как это у приложения нет response time?

Это глупый терминологический спор. Более важный вопрос здесь - сколько на свете приложений которые могут быть из коробки интегрированы с WLM что бы он мог смотреть на response time и считать среднее, всякие квантили, и уж тем более как то влиять на эти параметры.

[StrangerR]

160 логических процессора (по два на корову, всего 80 коров) .

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

Предположение про МФ не верно в корне. на zOS с WLM (а без него не бывает) можно гарантировать качество сервеса по требуемому параметру - респонс тайм и т.п.

На VMware тоже можно . Резервируете приложению все что нужно для нужного SLA и все.
Реальное время там прекрасно пашет, к примеру всякие там VoIP приложения.

[StrangerR]

Это не так. Память - да, физически резервируется но она на интеле настолько дешевлше чем на вашем МФ что и говорить смешно. А CPU - резервирование вовсе не отменяет возможность использовать неиспользованное CPU другими задачами, просто если все кто зарезервировал вдруг решат по максимуму на CPU сесть, другим не останется (если все что было зарезервировали). Ну и поставить еще одну железку, не МФ, крайне легко и быстро, если что, это вам не МИПСЫ у ИБМ-а за дикие бабки отлицензирровать, это пойти и заказатьт еще один сервер за $4K суммарной стоимости, делов то...

160 логических процессора (по два на корову, всего 80 коров) .

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

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

Тогда весь смысл виртуализании и консолидации, заключающийся в совместном использовании всех ресурсов сервера, изчезает и остаются только накладные расходы на виртуализацию и безопасность выполнения многих системных имиджей на одном сервере (or blade), вытекающая из банальной недоработки в этом плане тех систем, которые Вы гоняете на ВМ. Если последнее не так и системы Ваши надежны под любой нагрузкой, то Вы должны были бы в состоянии всю нагрузку запихать в одну систему (или несколько систем, не сотни) и не заморачиваться с виртуализацией.

[zVlad]

Как это у приложения нет response time?

Это глупый терминологический спор. Более важный вопрос здесь - сколько на свете приложений которые могут быть из коробки интегрированы с WLM что бы он мог смотреть на response time и считать среднее, всякие квантили, и уж тем более как то влиять на эти параметры.

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

Простые приложения не имеющие внутренней структуры единиц работы - транзакций, представляют собой одну транзакцию. Время выполнения такой транзакции можно конечно назвать респонс таймом, но правильнее его называть временем выполнения, или elapsed time. Но поскольку время выполнения одиночной программы случай уникальный и на основе ее выполнения невозможно собрать статистику необходимую для управления приоритетом, то для таких приложений имеет критерий (goal), называемый velocity, который используется для, скажим так, уникальных из условно бесконечных транзакций.

[Palych]

Как это у приложения нет response time?

Это глупый терминологический спор. Более важный вопрос здесь - сколько на свете приложений которые могут быть из коробки интегрированы с WLM что бы он мог смотреть на response time и считать среднее, всякие квантили, и уж тем более как то влиять на эти параметры.

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

Простые приложения не имеющие внутренней структуры единиц работы - транзакций, представляют собой одну транзакцию. Время выполнения такой транзакции можно конечно назвать респонс таймом, но правильнее его называть временем выполнения, или elapsed time. Но поскольку время выполнения одиночной программы случай уникальный и на основе ее выполнения невозможно собрать статистику необходимую для управления приоритетом, то для таких приложений имеет критерий (goal), называемый velocity, который используется для, скажим так, уникальных из условно бесконечных транзакций.

А если это Tomcat on Linux внутри Mainframe?

[StrangerR]

Ну короче, при такой цене памяти и единицы процессора как в МФ приходится извращаться. Так как понятно что достаточно разумного управления оным временем ответа в сложной системе сделать не удастся, и _евреи, кладите больше кофе_ куда лучше сработает чем многочисленные дыркозатыкатели из МФ. А кофе в МФ оооочень дорогое.

[Dmitry67]

Как это у приложения нет response time?

Это глупый терминологический спор. Более важный вопрос здесь - сколько на свете приложений которые могут быть из коробки интегрированы с WLM что бы он мог смотреть на response time и считать среднее, всякие квантили, и уж тем более как то влиять на эти параметры.

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

Простые приложения не имеющие внутренней структуры единиц работы - транзакций, представляют собой одну транзакцию. Время выполнения такой транзакции можно конечно назвать респонс таймом, но правильнее его называть временем выполнения, или elapsed time. Но поскольку время выполнения одиночной программы случай уникальный и на основе ее выполнения невозможно собрать статистику необходимую для управления приоритетом, то для таких приложений имеет критерий (goal), называемый velocity, который используется для, скажим так, уникальных из условно бесконечных транзакций.

Ваша логика показывает тот толстый слой пыли, который скопился на шкафах mainframes (и заодно в головах их архитекторов).

Когда пользователь заполнил информацию о том, куда он хочет лететь, и нажал 'Submit', и через некоторое время получил на экран список flights, это и есть с точки зрения response time. Он задал вопрос, ему ответили. Транзакция если здесь и есть, то read-only. Идите объясните пользователю что это 'elapsed' time. Или система проверки credit score по SSN - какой нибудь web service. запрос-ответ, разница - response time. Ктото перебегает улицу, вы давите тормоз в пол - response time. Я не вижу здесь никаких 'условно бесконечных транзакций' равно как и 'Простые приложения не имеющие внутренней структуры единиц работы'

В современном мире система распределены, и непрерывно обмениваются сообщениями. Ну а 'elapsed time' - это я помню, когда выполняешь JCL с FORT SYSIN.DD, то в конце печаталось сколько там CPU elapsed.

При многих потоках CPU elapsed может быть и больше и меньше response time, но собственно response time - это единственное, что заботит потребителя. Но в МФ мире все крутится не от потребителя, а от 'эффективной загрузки супер дорогого железа'

[zVlad]

Как это у приложения нет response time?

Это глупый терминологический спор. Более важный вопрос здесь - сколько на свете приложений которые могут быть из коробки интегрированы с WLM что бы он мог смотреть на response time и считать среднее, всякие квантили, и уж тем более как то влиять на эти параметры.

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

Простые приложения не имеющие внутренней структуры единиц работы - транзакций, представляют собой одну транзакцию. Время выполнения такой транзакции можно конечно назвать респонс таймом, но правильнее его называть временем выполнения, или elapsed time. Но поскольку время выполнения одиночной программы случай уникальный и на основе ее выполнения невозможно собрать статистику необходимую для управления приоритетом, то для таких приложений имеет критерий (goal), называемый velocity, который используется для, скажим так, уникальных из условно бесконечных транзакций.

Ваша логика показывает тот толстый слой пыли, который скопился на шкафах mainframes (и заодно в головах их архитекторов).

Когда пользователь заполнил информацию о том, куда он хочет лететь, и нажал 'Submit', и через некоторое время получил на экран список flights, это и есть с точки зрения response time. Он задал вопрос, ему ответили. Транзакция если здесь и есть, то read-only. Идите объясните пользователю что это 'elapsed' time. Или система проверки credit score по SSN - какой нибудь web service. запрос-ответ, разница - response time. Ктото перебегает улицу, вы давите тормоз в пол - response time. Я не вижу здесь никаких 'условно бесконечных транзакций' равно как и 'Простые приложения не имеющие внутренней структуры единиц работы'

В современном мире система распределены, и непрерывно обмениваются сообщениями. Ну а 'elapsed time' - это я помню, когда выполняешь JCL с FORT SYSIN.DD, то в конце печаталось сколько там CPU elapsed.

При многих потоках CPU elapsed может быть и больше и меньше response time, но собственно response time - это единственное, что заботит потребителя. Но в МФ мире все крутится не от потребителя, а от 'эффективной загрузки супер дорогого железа'

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

[zVlad]

Как это у приложения нет response time?

Это глупый терминологический спор. Более важный вопрос здесь - сколько на свете приложений которые могут быть из коробки интегрированы с WLM что бы он мог смотреть на response time и считать среднее, всякие квантили, и уж тем более как то влиять на эти параметры.

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

Простые приложения не имеющие внутренней структуры единиц работы - транзакций, представляют собой одну транзакцию. Время выполнения такой транзакции можно конечно назвать респонс таймом, но правильнее его называть временем выполнения, или elapsed time. Но поскольку время выполнения одиночной программы случай уникальный и на основе ее выполнения невозможно собрать статистику необходимую для управления приоритетом, то для таких приложений имеет критерий (goal), называемый velocity, который используется для, скажим так, уникальных из условно бесконечных транзакций.

А если это Tomcat on Linux внутри Mainframe?

В LPAR, или под zVM?