Естественно, причем зачастую (vmware) не copy on write а просто дополнительная копия изменений. В итоге в VMwarecrypto5 wrote:А copy on write нельзя снапшот реализовать? Я думал все снапшоты так и делают уже много лет.Dmitry67 wrote: А при бэкапе живого диска он разные части диска в разные моменты времени
А вот кстати, зачем эта опция нужна? С кластерами и бэкапом VM - фундаментальная проблема, которую с переменным успехом можно подвязывать веревочками хитроумными способами извещения приложений внутри VM о том что их бэкапят-восстанавливают, всякие синхронизации наружного и внутреннего VSS (в случае Windows/Hyper-V), и т.д.StrangerR wrote:Там есть опция _включать или нет сброс буферов из самой системы_ причем по умолчанию она включена
Опция не вредная - к примеру, может значительно уменьшить время восстановления после перевызова - журнал файловой системы будет сброшен, логи базы данных - обработаны и блоки записаны в файлы. Никогда оно не вредно. Но реально эта опция (кстати, довольно сложно найти как ее выключать) не очень надежно работает.Zombie416 wrote:А вот кстати, зачем эта опция нужна? С кластерами и бэкапом VM - фундаментальная проблема, которую с переменным успехом можно подвязывать веревочками хитроумными способами извещения приложений внутри VM о том что их бэкапят-восстанавливают, всякие синхронизации наружного и внутреннего VSS (в случае Windows/Hyper-V), и т.д.StrangerR wrote:Там есть опция _включать или нет сброс буферов из самой системы_ причем по умолчанию она включена
Но в случае одной VM без distributed transactions, если есть бэкап snapshot-а, т.е. памяти И дисков, то все недописанные буфера-кеши-транзакции, по идее, при восстановлении должны вернуться в исходное состояние, и дописаться/отвалиться по таймауту/и т.д. Зачем буфера сбрасывать?
Подытожим тесты, оставив пока вопрос об аккуратности постановки теста на МФ за скобками - диалог с Майком еще не закончен.iDesperado wrote:нашел убийственный аргумент. тесты реальной задачи. Peoplesoft
http://www.oracle.com/us/solutions/benc ... 67486.html
Итак берем 9-way z10 EC 2097-709 c DS8300 (6512 MIPS) проиграл 8-way SPARC Enterprise M5000 (32 cores) с флеш сториджом. причем заметно проиграл 87.4 минуты, против 50.11 минут. базы совершенно одинаковы, задача совершенно одинакова. у МФ было 8 потоков, у M5000 32.
8-way SPARC Enterprise M5000 (32 cores)
http://www.oracle.com/us/media1/ps9-na- ... 078501.pdf
9-way z10 EC 2097-709 c DS8300
http://www.oracle.com/us/solutions/benc ... 366176.pdf
....
Today’s System z Environment at PeopleSoft
- z10 EC model 709 with 9 general processors, 7 IFLs, 4 zIIPs and 1 coupling facility with
384 GB memory.
- DS8300 with 9 TB, multiple DS6800s
- 7 LPARs
• z/VM 5.4 running the z/Linux environment for test and development
• z/VM 5.4 running the z/Linux environment for benchmarking
• z/VM 5.4 running 15 z/OS images (1.6, 1.7, 1.8,1.9, 1.10 and 1.11) running the test,
development and support systems
• z/VM 5.4 running 14 z/OS images (1.6, 1.7, 1.8,1.9, 1.10 and 1.11) running the test,
development and support systems
• z/OS 1.10 running the benchmark environment
• z/OS 1.10 running the build systems
• z/OS 1.10 running system test
- Over 100 DB2 subsystems
• DB2 V7, V8 and V9
• DB2 V10 Beta initial testing underway
да, нет. я достаточно внимателен, а вот у вас явно начинаются проблемы с памятьюzVlad wrote: Вы не достаточно внимательно изучили предложенные Вами репорты, хотя там всего пять страниц в каждом включая булшир.
на самом деле меня в этом тесте не сильно интересовали абсолютные цифры в минутах. я в общем-то допускаю, что М5000 получил нехилое преимущество за счет флеш-дисков, но даже если в реальности 6512 MIPS в разы быстрее M5000 это эпик фол для платформы МФ. М5000 это машинка которая даже поуши забитая памятью и процами не потянет и на $200k, а МФ который мы с ним сравниваем, $6M. да я понимаю, что за эти $6М идет весь софт, который значительно дороже железячки, но все же совершенно очевидно, что по мощи M5000 вполне в одной весовой категории с МФ на 6000 MIPS, а вот по цене просто пропасть.zVlad wrote: Во-вторых, количество коров в тесте на МФ было не 9, а 8 следовательно MIPS не 6512, а 8/9 от этого числа. RAM на МФ - 24 GB. Соответствующие параметры у М5000 - 32 (правда на меньшей частоте 2.53 против 4.4 у МФ). RAM 64 GB.
тут не понял о каких других тестах идет речь. можно ссылочки на отчеты, откуда брались цифры ? я вроде кроме теста с "North American" не заметил тестов которые можно было бы сопоставить с zOS.zVlad wrote: Другие два теста дали следущие результаты:
Тест2:
М5000 - 512.95 минут
2097-709 - 230.57 минут
Тест 3:
М5000 - 884.91 минуты
2097-709 - 340.4 минуты
iDesperado wrote:....тут не понял о каких других тестах идет речь. можно ссылочки на отчеты, откуда брались цифры ? я вроде кроме теста с "North American" не заметил тестов которые можно было бы сопоставить с зОС.zVlad wrote: Другие два теста дали следущие результаты:
Тест2:
М5000 - 512.95 минут
2097-709 - 230.57 минут
Тест 3:
М5000 - 884.91 минуты
2097-709 - 340.4 минуты
А что данные о том для чего Оракл использует этот МФ в реальной жизни Вам ни о чем не поведали?iDesperado wrote:.....на самом деле меня в этом тесте не сильно интересовали абсолютные цифры в минутах. я в общем-то допускаю, что М5000 получил нехилое преимущество за счет флеш-дисков, но даже если в реальности 6512 МИПС в разы быстрее М5000 это эпик фол для платформы МФ. М5000 это машинка которая даже поуши забитая памятью и процами не потянет и на $200к, а МФ который мы с ним сравниваем, $6М. да я понимаю, что за эти $6М идет весь софт, который значительно дороже железячки, но все же совершенно очевидно, что по мощи М5000 вполне в одной весовой категории с МФ на 6000 МИПС, а вот по цене просто пропасть.
но главная ценность этих тестов все то, что они развенчали несколько созданных вами мифов о сказочных свойствах МФ:
1. тест в УНИЦОДЕ показывает 90% утилизацию процессоров. т.е. перед нами реальная задача, которая всего одним ДС8300 в котором максимум 16 фибре-чаннел/ФИЦОН (а сколько в тесте реально использовалось не известно). это говорит о том, что гигантское количество и/о каналов совершенно избыточно у МФ в сегодняшнем мире, а для того, что бы 6512 МИПС "захлебнулись" достаточно всего одного ДС8300 и 16 ФБ каналов.
2. тесты МФ без УНИЦОДЕ показали очень близкую к М5000 производительность, т.е. обе машины прожували примерно один и тот же массив данных, примерно за одно и то же время. при этом загрузка ЦПУ у них тоже была примерно на одном уровне. это означает, что на реальных задачах, не смотря на гигантскую частоту и оригинальную архитектуру, процессоры МФ сравнимы лишь со спарками, которые в мире персоналок сегодня далеко не чемпионы. очень далеко.
....
Хотелось бы узнать как Вы понимаете влияние UNICODE в связи с данным тестом и почему по-Вашему "захлебнулся" именно из-за UNICODE?iDesperado wrote:....1. тест в UNICODE показывает 90% утилизацию процессоров. т.е. перед нами реальная задача, которая всего одним DS8300 в котором максимум 16 fibre-channel/FICON (а сколько в тесте реально использовалось не известно). это говорит о том, что гигантское количество и/о каналов совершенно избыточно у МФ в сегодняшнем мире, а для того, что бы 6512 MIPS "захлебнулись" достаточно всего одного DS8300 и 16 FB каналов.
....
заметил, но не заметил таких цифр - 230.57 минут, 340.4 минуты. откуда это ? в этом отчете я таких цифр не вижуzVlad wrote:Ни хера себе (как говорит Бородач), Вы что не заметили в предложенных Вами репортаx три различных конфигурации выполнения "North American"?
лично мне, абсолютно ничего интересного.zVlad wrote:А что данные о том для чего Оракл использует этот МФ в реальной жизни Вам ни о чем не поведали?
уникоде я понял, что БД для этого теста была создана в кодировке utf8zVlad wrote:Хотелось бы узнать как Вы понимаете влияние UNICODE в связи с данным тестом
потому, что это единственно, что отличает тест от того, что в 58.96 уложился.zVlad wrote:и почему по-Вашему "захлебнулся" именно из-за UNICODE?
Page 3, Table 1 first rows with "Total Minutes" in first column.iDesperado wrote:заметил, но не заметил таких цифр - 230.57 минут, 340.4 минуты. откуда это ? в этом отчете я таких цифр не вижуzVlad wrote:Ни хера себе (как говорит Бородач), Вы что не заметили в предложенных Вами репортаx три различных конфигурации выполнения "North American"?
http://www.oracle.com/us/solutions/benc ... 166431.pdf
.
Это ровным счетом ни о чем не говорит. Современные крупные компании любят посщекотать нервы другим конкурирующим компаниям сообщениями о сотрудничестве и кооперировании. На самом деле все может быть по разному в каждом конкретном случае. По нашему конкретному случаю вот что мне только что ответили из ИБМ:iDesperado wrote:.....и кстати теперь понятно кто делал бенчмарки, делали IBM Oracle International Competency Center in Pleasanton, CA. т.е. делались с привлечением спецов от IBM.
вот их описание
http://public.dhe.ibm.com/common/ssi/ec ... 96USEN.PDF
Ok, from one of our senior DB2 guys.. He says we did not participate in
anyway in the Oracle tests, and have no knowledge therefore of what
they did/did not do tuning wise. We have to be careful what is said..
Это меня не удивило. Более того, я уверен что процентов 90 того что я здесь говорю о МФ не доходит до Вашего сознания и не осмысляется. Я это знаю, например, по такому Вашему перлу:iDesperado wrote:....лично мне, абсолютно ничего интересного.zVlad wrote:А что данные о том для чего Оракл использует этот МФ в реальной жизни Вам ни о чем не поведали?
...
... для того, что бы 6512 MIPS "захлебнулись" достаточно всего одного DS8300 и 16 FB каналов
До сих пор были известны только лошадиная сила, удав и попугай. 
хи-хи, по вашему оракл темной ночью выкрал МФ у IBM и создал фиктивный центр и путем угроз заставил IBM написать о том, что в этом центре 10 тысяч IBM-спецов ? если это так, то чо делал в этом центре Mike Curtis в январе 2010 ?zVlad wrote: Это ровным счетом ни о чем не говорит. Современные крупные компании любят посщекотать нервы другим конкурирующим компаниям сообщениями о сотрудничестве и кооперировании. На самом деле все может быть по разному в каждом конкретном случае. По нашему конкретному случаю вот что мне только что ответили из ИБМ:
ну вы хоть намекните, а то у меня даже идей нет в каком направлении копать и что за данные у вас "для чего Оракл использует этот МФ в реальной жизни"zVlad wrote: Это меня не удивило. Более того, я уверен что процентов 90 того что я здесь говорю о МФ не доходит до Вашего сознания и не осмысляется.
Да, я тоже заметил и думаю другие заметили также. Теперь будем спорить о том, чья корова дает больше молока (МИПСолока), у какой коровы молоко белее и просто правильное. Фермы серверов [server farms] тоже удобно считать по поголовью коров. А мейнфреим консолидирует коров и загоняет их на меньшую площадь под управлением меньшего числа (но более суровых и маркситски подкованных) пастуховsp123 wrote:Немножко оффтопика для разрядки обстановки. В нескольких постах от разных участников очень порадовала фраза типа "количество коров в тесте ... было ...". Кажется, в этом топике мы присутствуем при знаменательном событии - рождении новой единицы измерения мощности компьютерной железяки - "корова".
Чтобы вам легче было понять скажу что IFL - это CPU для линукса. Т.е. в данном случае речь идет о замене только железа. Основной софт остается тем же, видимо это Оракл.Vlad:
A comparison of just hardware costs will almost always show the mainframe as higher cost, however it is the total costs which really matter. I did a sizing just yesterday to migrate an Oracle environment running on Sun Solaris (three T6320 blades and four M8000 servers with a total of 68 cores and 768 GB of memory) to System z. The System z sizing was 13 z196 IFLs and 300 GB of memory. The big difference here is the Oracle licenses costs at 78 licenses (after applying the core factor) on Solaris vs 13 on System z. When all the items are added up, System z is lower cost just on TCA and only gets better if you look at TCO.
Точно. Только мне казалось что этот термин - корова - уже давно гуляет.flip_flop wrote:Да, я тоже заметил и думаю другие заметили также. Теперь будем спорить о том, чья корова дает больше молока (МИПСолока), у какой коровы молоко белее и просто правильное. Фермы серверов [server farms] тоже удобно считать по поголовью коров. А мейнфреим консолидирует коров и загоняет их на меньшую площадь под управлением меньшего числа (но более суровых и маркситски подкованных) пастуховsp123 wrote:Немножко оффтопика для разрядки обстановки. В нескольких постах от разных участников очень порадовала фраза типа "количество коров в тесте ... было ...". Кажется, в этом топике мы присутствуем при знаменательном событии - рождении новой единицы измерения мощности компьютерной железяки - "корова".
Я его уже год как в сеть запустил, а может он и раньше там был. Как и КрабоРак.zVlad wrote:
Точно. Только мне казалось что этот термин - корова - уже давно гуляет.
МФ Оракл купил у ИБМ для собственных нужд. Оракл осуществляет свои разработки и саппорт для МФ на этом МФ. В этом центре точно нет 10 000 специалистов, их вообще столько нет ни у Оракла ни у ИБМ по этой теме.iDesperado wrote:хи-хи, по вашему оракл темной ночью выкрал МФ у IBM и создал фиктивный центр и путем угроз заставил IBM написать о том, что в этом центре 10 тысяч IBM-спецов ? если это так, то чо делал в этом центре Mike Curtis в январе 2010 ?zVlad wrote: Это ровным счетом ни о чем не говорит. Современные крупные компании любят посщекотать нервы другим конкурирующим компаниям сообщениями о сотрудничестве и кооперировании. На самом деле все может быть по разному в каждом конкретном случае. По нашему конкретному случаю вот что мне только что ответили из ИБМ:
...
Это Ваши досужие домыслы, а пока что по крайней мере в одном месте и буквально вчера МФ выиграл с разгромным счетом Sun сервера. И это факт.StrangerR wrote:..... Но все равно рак с блейдами от делла выиграет у МФ с разгромным счетом и по всем практически показателям.
не похоже, из презенташки, в которую вы нашлиzVlad wrote: Mike Curtis работает не в IBM Oracle ICC, а чисто в Оракл. По крайней мере так следует из его подписи в e-mail. И, насколько я понимаю, работает там (начиная в PeopleSoft) уже 13 лет.
Не понятно почему конфигурацию МФ с 13 процами и 300 гб посчитали эквивалентной системе с 68 корами и 768 гб?zVlad wrote:Это Ваши досужие домыслы, а пока что по крайней мере в одном месте и буквально вчера МФ выиграл с разгромным счетом Sun сервера. И это факт.StrangerR wrote:..... Но все равно рак с блейдами от делла выиграет у МФ с разгромным счетом и по всем практически показателям.
Мне почему то кажется что это типичная "success story" в которой сильно outdated железо одной платформу меняют на современное железо другой.crypto5 wrote:Не понятно почему конфигурацию МФ с 13 процами и 300 гб посчитали эквивалентной системе с 68 корами и 768 гб?zVlad wrote:Это Ваши досужие домыслы, а пока что по крайней мере в одном месте и буквально вчера МФ выиграл с разгромным счетом Sun сервера. И это факт.StrangerR wrote:..... Но все равно рак с блейдами от делла выиграет у МФ с разгромным счетом и по всем практически показателям.