Бенчмарки Solaris 10

> а то, что бимеры умеют делать SMP системы это всем известно, так же как и сколько они, собаки, стоят.

А типа значит E25K суновский прямо как машинка для дома, для семьи? :-)

> ну а если об администрировании и надежности речь пойдет...

То ничем железки не отличаются. Дублирование - оно и в Африке дублирование.

По ссылкам видно, что уже после 4 процов производительность Линукса начала спадать, в то время,как у Сан падение началось на 92 процах. Так в чем крутость Линукса?

>А типа значит E25K суновский прямо как машинка для дома, для семьи? :-)

А ты сам проверь. и учти, что бимеры продадут только практически голую систему и сдерут с тебя втридорога за каждую фичу.

> Дублирование - оно и в Африке дублирование

речь была не о железках

> А ты сам проверь. и учти, что бимеры продадут только практически голую систему и сдерут с тебя втридорога за каждую фичу.

Хе-хе... Ну а в Sun, конечно, ангелы :)

Саныч, достал.

Следующие твои сообщения со словом "ляпикс" будут удаляться по 5.5

> уже после 4 процов производительность Линукса начала спадать в то время,как у Сан падение началось на 92 процах

А так и должно быть. RTFM спецкурс методы оптимизации (это такой раздел математики).

Или ты смайлик забыл?

Если честно, то я нифига не понял, кто что и как мерял. Для начала, я так понимаю, надо на одном и том же железе, под разными ОС сравнить одну и ту же жабу. Потом уже пузомерки гонять. А так сравниваем помидоры с огурцами и делаем вывод, что огурцы длиньше.

> Если честно, то я нифига не понял, кто что и как мерял

Есть тестовый набор данных и инструкция, что надо с ними сделать :-) Сделать надо как можно больше и как можно быстрее (или столько же за меньшее время, или больше за то же время - эти утверждения эквивалентны :-). Обсуждаемые тест используется как тест производительности комплекса железо+ОС+JVM. При прочих равных можно сравнивать отдельные компоненты :-)

> речь была не о железках

И что? Или теперь на курсе "Sun Systems Fault Analysis" про гнилые разборки посмертных дампов ядра чисто для общего развития рассказывают? Не знал, не знал... А ведь чуть не пол-дня из пятидневного курса на это дело угробили... :-)

Охренеть!!!! А поставить видео постить какие результаты будут???????

солнцевские так и меряли, но прибежала даша и сказала, что это фигня, пиар и контрреволюция

> Или теперь на курсе "Sun Systems Fault Analysis" про гнилые разборки посмертных дампов ядра чисто для общего развития рассказывают?

а почему - гнилые? ;) вполне нормальные себе такие разборки с мертвячиной.

> А ведь чуть не пол-дня из пятидневного курса на это дело угробили... :-)

Мало. Только по применению adb/mdb на крешдампах можно прочитать двухнедельный курс. Правда, еще неделю займет SPARC Assembler. ;) А если X86 - то две-три.

> но прибежала даша и сказала, что это фигня, пиар и контрреволюция

Предлагаю всем обиженым и недовольным идти на... В смысле идти в Talks и организовать тред по обсуждению того, как вас обидел no-dashi. Или у вас уже стойкая фобия выработалась, и я теперь и колеса вашим машинам проколол, и всемирный сионистский заговор организовал, и по ночам вам телепатическими сигналами кошмарные сны нагоняю, и путем телекинеза спровоцировал землетрясение в азии?

> солнцевские так и меряли

Тра-та-та, я уже ткнул пальцем, что бенчмарки на примерно одинаковых машинах (на самом деле солярис работал на более быстром процессоре - 2.6GHz для соляриса против 2.4GHz для RedHat'а) показывают превосходство в производительности даже 32-битного Linux'а над 64-битным солярисом. И пофиг какого размера там "адресное пространство процесса", поскольку _на _приведенном_ _тесте_ это самое "адресное пространство" выигрыша не дало.

> самое "адресное пространство" выигрыша не дало.

а с каких это пор "адресное пространство" дает выигрыш?

> а с каких это пор "адресное пространство" дает выигрыш?

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

P.S.: вот от тебя я такого не ожидал :-(

а ты just for fun почитай. и вспомни что ты не на винфаке

>Большое адресное пространства процесса дает возможность сильно увеличить всяческие кэши, буферы и прочие "потроха" различного софта типа серверов БД, позволяет удерживать в мозгах больше данных для серверов приложений и т.п.

забыл добавить - путём вскрытия корпуса и добавления новых планок ОЗУ :-)

> 1. Смотрим http://www.spec.org/jbb2000/results/res2005q1/jbb2000-20050214-00305.html - 16-ти чиповый Power, по 2 ядра на кристал, с "липуксом" на борту - 1076309

> 2.Смотрим http://www.spec.org/jbb2000/results/res2005q1/jbb2000-20050201-00278.html - 44-х чиповый спарк, 88 ядер - 645042

> И как это весь такой "тормозной липукс", запущеный на 32-х процессорах в полтора раза уделал всю такую "реально крутую" солярку, которая бегала аж на 88 ядрах (44 кристала)?!

Всё очевидно, у Power частота выше в полтора раза и кэш 3-го уровня 144 метра на камень.

Хочешь посравнивать Линукс и Юникс - сравнивай на одном железе. Например , если уж на Power, то сравнивай с AIX на том же железе. Если на SPARC, то и Линукс на нём же поднимай.

И ещё - некорректно сравнивать 32- и 64-бит тесты между собой.

> Большое адресное пространства процесса дает возможность сильно увеличить всяческие кэши, буферы и прочие "потроха"

ага. и уменьшить число инструкций в кеше процессора, например. кроме того, ограничение в 2-3GB (в зависимости от) критично для довольно больших баз данных. и ты сам это знаешь.

> P.S.: вот от тебя я такого не ожидал :-(

вопрос остался в силе. слив пока не засчитан. ;)

> И ещё - некорректно сравнивать 32- и 64-бит тесты между собой

Не притягивай за уши лишние сущности. Факты гласят - на аналогичном железе Linux оказался производительней - т.е. проделывает БОЛЬШЕ транзакций за то же самое время.

Аналогия - ты можешь обзавестись навороченнейшей винтовкой калибра 14мм (SMP) с дальностью боя 1.5км (64 бита и поддержка докуя процессоров), оптикой с 50-ти кратным увеличением (dtrace), прикладом из красного дерева (настоящий UNIX :-)) и гарантией производителя на ресурс ствола в 1 миллион выстрелов (поддержка), но стоит тебе только выйти с этим чудом технологий в лес или в город, как мужик с дробовиком (linux) замочит тебя с дистанции 20 метров (32 бита).

Суновцы вышли со своей "винтовкой" (Solaris) в условия, где рулят дробовики (Linux). И вполне закономерно, что по производительности (остаться в живых) их "законопатили".

> Всё очевидно, у Power частота выше в полтора раза и кэш 3-го уровня 144 метра на камень.

Правильно. И значит Sun отдыхает. Измеряется ведь суммарная производительность, не так ли? Сие означает, что решение с Linux оказалось лучше, чем решение с Solaris.

>Всё очевидно, у Power частота выше в полтора раза и кэш 3-го уровня 144 метра на камень.

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

>И ещё - некорректно сравнивать 32- и 64-бит тесты между собой.

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

> кроме того, ограничение в 2-3GB (в зависимости от) критично для довольно больших баз данных.

Правда? Ты же знаешь, что я всегда приведу пример - хотя бы такой: есть таблица, в 10 миллионов записей, по 200 байт каждая (не так уж и много, верно? :-)). Общий вес таблички - 2GB

Ок. Делаем select * from tablename order by formula(fieldvalue). На системе с большим адресным пространством мы можем удержать в памяти весь объем данных (2GB), и отсортировать их также в памяти (+ еще 2GB) да плюс объем кода, билиотек, ядра и т.п. И все, на 32-х битах такой фокус не пройдет - а 64-х битная машинка получила "чистое" преимущество.

Достаточно? :-)

Можно еще привести другие примеры, но лень.

Дурик ты Даша.

Винтовка - нарезное оружие и на 20 метров никто мужика не подпустит.

>Винтовка - нарезное оружие и на 20 метров никто мужика не подпустит.

Нарезная винтовка за угол не стреляет :)

<offtopic>

> Винтовка - нарезное оружие и на 20 метров никто мужика не подпустит.

Да ну? После выстрела без ПББС снайпер покидает позицию в течение 3-5 минут (из личных бесед с одним человеком). Именно из-за того, что даже самая навороченная винтовка в городе не может сравняться с "лейкой" АКС-74У, у которой с 40 метров уже разброс как после похмелья.

</offtopic>

>> Винтовка - нарезное оружие и на 20 метров никто мужика не подпустит.

> Да ну? После выстрела без ПББС снайпер покидает позицию в течение 3-5 минут (из личных бесед с одним человеком). Именно из-за того, что даже самая навороченная винтовка в городе не может сравняться с "лейкой" АКС-74У, у которой с 40 метров уже разброс как после похмелья.

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

Касательно винтовок и Solaris.

Для винтовки идеальной сферой применения является поле с огромной прямой видимостью, что редко бывает на практике. Так же и для Solaris существуют специальные тесты, где он быстрее.

Но практика показывает, что в системе используеются компоненты не созданные специально по тем технологиям, которые обеспечивают выигрыш в тестах, т.о. если теоретически все заоптимизировать под Solaris [читай, переписать все с нуля], то возможно он и покажет 50% превосходство.

В то же время Linux является таковой системой, в которой даже без оптимизаций обнаруживается серьезное превосходство. Что же говорить о том, каковы будут результаты, если оптимизировать для конкретного дистрибутива...

>в которой даже без оптимизаций обнаруживается серьезное превосходство

Бабушке своей это расскажи.

Линупс начали натягивать на глобус (64 бита) уже потом.

Что объясняет тот факт, что HPUX на итаниках линукс тоже проигрывает.

> Ок. Делаем select * from tablename order by formula(fieldvalue).

Во-первых, делаем _два_ селекта подряд. Во-вторых, и ты сам это знаешь, что в памяти все равно будет хранится пара сегментов и только. Ну, пусть не пара, а больше, но все равно не весь результат селекта. Это, конечно, не сколько проблема 64bit, сколько оракла, наверное. Я думаю - потому что он 32-битное наследие тянет где-то внутри. А может, и нет. Я не настолько компетентен в этом вопросе.

Кроме того, это хорошо только тогда, когда у тебя _есть_ эти 4+ GB оперативки. А то оракле по доброй традиции сделает гигантский malloc, который потом весь в swap уйдет.

> Достаточно? :-)

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

Но в общем, я согласен, больше памяти - лучше. Только одних 64bit - не достаточно.

> Что объясняет тот факт, что HPUX на итаниках линукс тоже проигрывает.

Мне хапешники показывали тесты, где чпукс выигрывал. Раза в два.

Скорее, наоборот. У Solaris - лучшие SMP-модель и и KAIO из хрюниксов под x86. Так что на многоголовых машинах solaris уделывает linux. Не в разы, но ощутимо.

> Вопрос в том, что помогает ли это в данном конкретном тесте, или нет.

Ну да, в тесте jbb пример с базами данных действительно не очень описателен. В основном потому, что storage, скорее всего, на другой машине :-)

Но и в этом тесте размерность и количество памяти, потенциально (да и фактически) доступной процессу достаточно важна. Например, есть подозрение, что моменты срабатывания GC в JVM весьма сильно зависят от соотношения использованной/свободной памяти (хотя за это поручиться не могу - у меня нет кода сановского JRE :-)) [маленькая демонстрация - в 32-х битных Linux'овых JRE чуть ли не в обязательном порядке необходимо вызвать GC когда количество использованной памяти приблизится к 1.5 GB, на 64-х битах этот момент может быть отложен]. Всяческие хэши и прочее могут работать быстрее (можно выдавать побольше памяти уже при создании объекта, что позволит отложить или вообще избежать переразметки массивов), распределять память можно большими блоками (больше размер блока -> меньше операций -> меньше фрагментация -> выше процент попадания в кэш -> выше производительность).

В общем, большой адресуемый объем изначально дает возможность более эффективно работать.

"Болезнь" Sun в том, что их верхние машины неадекватно дороги по соотношению цена/производительность и недостаточно стабильны, увы. В то же время midrange у Sun великолепный - 4800/E4900, 6800/E6900 отличные машины, производительные и надежные. А вот у IBM, например, даже в новой серии p5, в которую вбросили немало технологий из линейки iSeries, все равно не появилось адекватного midrange.

Так что если и гонять тесты на больших машинах - надо принимать в расчет, допустим, p5 595.

> Так что на многоголовых машинах solaris уделывает linux

Так почему он оттал от 32-х битного Linux на 4-х процессорах? Типа другая JVM? Так тогда Sun ССЗБ :-)

>>в которой даже без оптимизаций обнаруживается серьезное превосходство

>Бабушке своей это расскажи.

>Линупс начали натягивать на глобус (64 бита) уже потом.

>Что объясняет тот факт, что HPUX на итаниках линукс тоже проигрывает.

Мой юный друг, ты снова вырываешь фразы из контекста.

Линукс уже тогда выигрывал, и выигрывал серьезно.

Сан задумался, подсмотрел идеи, что-то исправил... - "заоптимизировал", одним словом, тест под свою платформу и выдал результат. И оказалось, что Линукс проигрывает. И даже если гипотетически предположить, что тест полностью корректен, его результаты получены от накачанного стероидами Соляриса, который всегда был медленнее. Почему в течение 10 лет он не смог вырваться вперед? Почему Линукс его всегда существенно опережал?

Стоит повторить этот тест в других лабораториях, где оба претендента оптимизированы и настроены, и мы видим [по приведенным ссылкам], что ситуация не изменилась за 10 лет - Солярис отстает, и она просто не может измениться.

Как вдруг труп, который тащит в себе все ошибки и недоработки прошлого (Сан это называет _это_ обратной совместимостью), вдруг приобрел красивый цвет лица?

ЧМОКЕ ТИЕ ВОВЧЕК В ЕТАМ КЛЕВАМ ФОРУМИ!!!

Была веселая ситуевина, когда мы делали в Монпелье сайзинг банковской аппликухи на AIX 5L/p690/POWER4, а веселые ребятишки из HP - на 11i/Itanic. Вдрук оказалось, что таки да, 1 Itanic в два раза производительнее 2 ядер POWER5. При предъявлении результатов заказчику был скандалъ, так как "профиль" тестирования на HP-UX моделировал вчетверо меньшее количество проводок.

Это я к тому, что умеючи, можно многое подкрутить :)

Видишь ли, особенности моей работы таковы, чтобы из псевдонаучного и псевдотехнического маркетингового бреда вендоров, вычленять рациональное зерно. У меня большой опыт крупных сайзингов, моделирующих, например, 15000 активных пользователей ЦАБС realtime.

То, что публикуется, как правило профинансировано самим же вендором, и в расчет может приниматься только с очень большой скидкой на маркетинг. Я более чем уверен, что если мы начнем сайзить описанные конфигурации под реальную heavy-duty задачу, solaris или AIX таки победят. Не потому, что они такие хорошие, просто они лучше всего подходят под тяжкий workload на 64-bit.

> ЧМОКЕ ТИЕ ВОВЧЕК В ЕТАМ КЛЕВАМ ФОРУМИ!!!

ДенисЮрич!

> Это я к тому, что умеючи, можно многое подкрутить :)

Само собой. Я ж демонстрировал свои "тесты", где UltraSPARC IIi 300MHz делал iTanium 1GHz. ;)

Достал уже своим упрямством.

Просто это особенность оптерона хорошо работать с 32 битными

приложениями.

И этого факта совершенно нельзя сделать вывод, что 64 битный линукс

будет быстреее соляры на оптероне.

Suse ведь проиграла?

Пускай РедХат покажет свои результаты для новых 64 битных ентерпрайз

линуксов и тогда будет предмет для обсуждения.

> Так почему он оттал от 32-х битного Linux на 4-х процессорах? Типа другая JVM? Так тогда Sun ССЗБ :-)

4 камна - это не многоголовый. Весь цимус начинается с 8, а лучше - с 16.

Sun-ch:

> Линупс начали натягивать на глобус (64 бита) уже потом.

Он почти с рождения был 64-бит чистым. "Натягивали" всякие юзеровские приблуды и драйверы, которых под Солярой вообще нет.

> Что объясняет тот факт, что HPUX на итаниках линукс тоже проигрывает.

Год назад мне пришлось тестировать не абстрактную, но реальную пузомерку, сделанную нами для оценки наших потребностей. На этой пузомерке на Итаниках Хпукс слил Линуксу и в масштабируемости, и в абсолютной производительности. Я был удивлен, но факты таковы: на 32-итаниумном Альтиксе под Линуксом наши задачи бегали лучше, чем на аналогичном железе от HP под Хпуксом. При том, что решение от HP было (эффективно) раза в 2 дороже.

таким образом по соотношению цена\производительность солярка точно сливает линуху =)

и пиво на халяву не имеет конкурентов по соотношению цена/качество

ну-ну... до выхода OpenSolaris осталось недолго...

> до выхода OpenSolaris осталось недолго...

... а майкрософт обещало сделать "объектную" ФС еще в NT4 :-)

Отлично сказано! Очень живая аналогия! Особенно про приклад. ;-) Респект.

саныч, да что ты так переживаешь-то?
доказываешь что черное это белое... детский сад, честное слово :))
мне тут знакомые пацаны, которые санками рулят непадецки и вечно пальца гнут от этого по секрету сказали (после второй бутылки) что гавно это страшное и вообще непонятно как оно работает. без гнутых утилей, без компилера и прочих радостей жизни, но зато с ФС, которая от каждого чиха рассыпается и HCL такой длинны, что в приличном обществе и показать-то стыдно :))

> но зато с ФС, которая от каждого чиха рассыпается

Ну, не все так грустно... Сановцы всегда умели удалять гланды через задний проход - например, придумав background fsck :-)

Конечно же на сайте Sun...

Кто как, а я этой компании после недавних заявлений ни на грош не верю. Можно сказать появился новый Get The facts

ты очень разумно поступил, что не спросил у них, что они думают про лялих :-)

100 :)

Что же вы остановились. Такой интересный был флейм! Пока что договорились только что все ацтой :)

Аффтар пиши есчо!