С0ВЕСТЬ --null--Солярка перестала быть BSD-шной системой ещё начиная с Solaris 2.6
Меня сейчас не это интересует, а производительность Солярки возле других юниксовых систем

А какая платформа интересует?

С0ВЕСТЬИнтересует платформа:
x86,
а юзать в учебных целях будем
Оракл 10.
Солярка насколько производительней линукса, фрибсд?

Ядро Solaris устроено сложнее линаксов и бздей, поэтому в ряде случаев при нулевой нагрузке работает медленнее, т.к. выполняется большее количество кода. Количественно это можно выразить в долях процента. Разумеется, можно написать такое приложение, которое будет медленно работать на Solaris, но быстро - на линаксе; верно и обратное. Oracle к таким забавным приложениям не относится.
Подобные исследования (кто кого быстрее) имеют разве что академическую ценность, поскольку в практических задачах играют совсем иные факторы: масштабируемость, отказоустойчивость, управляемость, пригодность к диагностике (как на лету, так и post mortem), документированность, наличие и качество технической поддержки. По таким практическим критериям Solaris оставляет все наколенные поделия далеко позади.

мнение Scott Tiger С0ВЕСТЬИнтересует платформа:
x86,
а юзать в учебных целях будем
Оракл 10.
Солярка насколько производительней линукса, фрибсд?

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

Но тем не меннее, что бы не было иллюзий у тех кто решил обольститься солярой, приведу пример.
У нас Solaris SPARC 9. За последние пару месяцев было два случая с двумя разными серваками - умерли мгновенно с последующей автоматической загрузкой.
Или буквально сегодня: после команды: alter database backup controlfile to trace БД Oracle упала.

"Умерли", "упала" - это не серьёзно. Какой именно отказ был? Что упало? Почему упало? Какая диагностика проведена и каковы результаты? Понимаешь, если у тебя вылезает, например, некорректируемая ошибка в незеркалированном модуле памяти, на который попалась неперемещаемая страница ядра, ОС перезапустится без вариантов. Или там патч Бармина кто-то втихую накатит. Или аппаратный отказ, несовместимый с нормальной работой.

мнение Scott Tiger
"Умерли", "упала" - это не серьёзно. Какой именно отказ был? Что упало? Почему упало?

А какая в принципе разница в контексте объяснения клиентам, почему они не могли работать в своих программах, использующие БД Oracle и в контексте безоговорочного утверждения(мифа) о соляре и сановском оборудовании, как о высоконадёжном?

По первому падению сан ответил просто типа: "ну упало, упало - бывает"

Не бывает 100% отказоустойчивых систем, и, чем ближе к заветной цифре, тем ближе сумма счёта к бесконечности :). Оборудование разных вендоров имеет близкие показатели надёжности, если не брать в расчёт специфичные функции отказоустойчивости; сложно как-то специально серийно производить полупроводниковый девайс, чтобы он работал ненадёжно относительно других девайсов, скорее, может быть дело в конкретном экземпляре. Об отказе какого рода вообще идёт речь? Что было во второй раз? Каким образом связан отказ приложения (Oracle) с операционной системой или железом?

"Упало - бывает" вряд ли могли ответить, не верю. Скажи номер заявки в Sun или серийник железки и дату отказа, мне любопытно, лучше в личку scott тчк tiger сбк sun тчк com. Другое дело, если, например, система настроена/подключена таким образом, что вся диагностика уходит в /dev/null (а такие деятели попадаются) и можно бесконечно долго гадать, что же произошло, что привело к отказу.

мнениесбои бывают и даже на таком оборудовании.

Сбои бывают на любом оборудовании, и чем сложнее оборудование, тем более вероятно возникновение сбоев (другое дело, что серьёзные железки имеют более развитые возможности делать эти сбои нефатальными для пользователя). Банальный пример - в больших железках, типа 6900 и выше, модули памяти вылетают (некорректируемые ошибки или большое, выше порога, количество корректируемых) заметно чаще, чем такие же модули в мелких машинах. Это связано не с тем, что память там специальная ненадёжная или конструкция процессорной платы неправильная, вызывающая сбои, а с тем, что в мелкой машинке типа V240 всего 8 слотов для модулей памяти, в 6900-м уже 192, а в E25K в полной конфигурации - целых 576. Но большой железке отказ одной планки памяти в большинстве случаев - что слону дробина, а для мелкой это и чувствительная потеря объёма и, при неудачном раскладе, даунтайм (page retirement рулит нипадеццки, кстати). Аналогично и с большими дисковыми системами любого производителя - отказы единичных дисков происходят с пугающей частотой именно потому, что дисков много, а не потому, что диски в больших системах хуже, чем в мелких. Просто дисков очень, очень много :)

мнение

А Oracle сегодня упал после backup controlfile to trace - для меня это было шоком. Хотя возможно это случайное совпадение и не в этой команде дело, потому что команда фактически отработала, трейс создался и первое сообщение о падении процессов(в итоге всё упало) началось через 2 минуты только.

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

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

Ну если ты DBA, то скажи, как именно упал Oracle - какие ошибки, или там в корку кто свалился...

мнениеИх там очень много - мы смотрели на металинке, но ничего конкретного не нашли.
Вот только кусок от начала.

[src]ORA-00600: internal error code, arguments: [6002], [0], [0], [2], [0], [], [], []
Tue Jul 1 11:31:22 2008
ORA-07445: exception encountered: core dump [kcbzgm()+1224] [SIGBUS] [Invalid address alignment] [0x3F5] [] []
Tue Jul 1 11:31:22 2008
ORA-07445: exception encountered: core dump [kcbgtcr()+6732] [SIGBUS] [Invalid address alignment] [0x190025] [] []
Только ты незамарачивайся. Не трать зря время. Патчи мы всё равно не ставим - продакш всё таки. Одно вылечишь - другое сломается. Если будет повторятся - тогда наверно задумаемся.

Проблема, скорее всего, индуцирована ОС. Я бы на твоём месте над трассировками от 7445 и корками в core_dump_dest помедитировал. А патчи ставить надо, если, конечно, прописано :)

Relic Hunter Scott Tiger
Проблема, скорее всего, индуцирована ОС. Я бы на твоём месте над трассировками от 7445 и корками в core_dump_dest помедитировал. А патчи ставить надо, если, конечно, прописано :)Хм... Как ошибка Оракла связана с ОС? На металинке явно написано про ORA-00600 arguments: 6002 и как это надо лечить.

В комплексе с 25012, неопубликованной 15767 и кучей других упомянутых, но не приведённых в посте ошибок, сильно похоже на повреждение SGA. В принципе, повреждение могло произойти и из-за какого-либо ораклового бага и словить SIGBUS при коррапнутой SGA - милое дело. Но могло быть и влияние ОС. Я бы лично копал с двух сторон - во-первых, почему/где получаем SIGBUS (что пытаемся сделать непосредственно перед этим), а, во-вторых - иметь голову оракловому саппорту.

Я, кстати, порылся таки по металинку - на первый взгляд, люди иногда ловят чем-то похожие проблемы через несколько минут после backup controlfile to trace. Например, кроссплатформенный (к вопросу о солярке :)) баг 6789755 (тж. см. его базовый баг).

Есть рыба-пила и есть рыба-молот. Вот только не понятно, что они там строят...

Relic HunterНа металинке явно написано про ORA-00600 arguments: 6002 и как это надо лечить.

Очень пикантны нулевые значения первых двух аргументов, не находишь? :) Вот ещё по 25012 мысль и вопрос автору - а не проводились ли манипуляции с таблеспейсом TEMP (обычно он имеет номер 3) незадолго до backup controlfile to trace? Чёт очень похоже, особенно если среди кучи ошибок присутствует и, например, ORA-00600 [2103]...

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

Есть рыба-пила и есть рыба-молот. Вот только не понятно, что они там строят...

мнениеСмысл надёжного оборудования, если багов в самом приложении ничуть не меньше чем для других осей.

Смысл в том, чтобы наша хата была с краю :) У того же Oracle есть некоторое количество платформоспецифичных багов, сравнить их количество для разных платформ можешь попробовать сам.

В любой ОС есть масса нюансов, которые так или иначе влияют на работу приложения, порой - деструктивно. Когда исследуешь неожиданно возникшие на стыке технологий проблемы, требуются хорошие диагностические средства, т.к. нередко возникают ситуации, когда вроде бы всё штатно, ожидаемо, работает, а результат, с точки зрения конечного пользователя, плачевный. И здесь на руку Solaris играет как раз наличие и документированность уникальных средств, позволяющих разобрать систему до винтиков. Плюс есть исходники (хотя, конечно, это пока несколько идущий перед коммерческой версией OpenSolaris, но, в немалом количестве случаев, можно использовать и их). Возьмём тот же DTrace - возможно, количество пиара вокруг этого механизма может показаться кому-то слишком большим, но это действительно уникальная в своей полезности (из личного опыта, в том числе) штука для анализа программных проблем, от простейших до самых сложных. Аналогов либо нет, либо они находятся в зачаточной стадии развития и не используются (SystemTap в линаксе), а DTrace давно есть в релизах, стабильно работает и нередко применяется на продуктивных системах.
Ещё момент - поддержка многопроцессорных и, вообще, больших (например, по количеству памяти) систем, хотя мировой тренд на многопроцессорные системы с большим объёмом памяти очевиден. Линаксы и проч. изначально не были ориентированы на подобное железо (логично - начиналось всё как домашний проект), нормальная поддержка SMP реализована совсем недавно, при том что на больших машинах столько разнообразной специфики, связанной с их архитектурой, что требуется реально большая работа для получения хорошо масштабируемого продукта. Зачастую энтузиаст-разработчик не имеет возможности протестировать работу своего кода на действительно большой системе, там, где количество уже переходит в качество, как результат - проблемы с масштабируемостью. В то же время Solaris с незапамятных времён работает на очень больших во всех измерениях железках.
Линакс-опенсос это всё круто и весело, но там всё хорошо будет когда-нибудь, а в Solaris всё хорошо есть уже сейчас. Не бывает так, что сел, написал и - хопа - заработало идеально. Нужно время, и у Solaris в этом смысле хорошая фора.

Яриска Scott Tiger Возьмём тот же DTrace - возможно, количество пиара вокруг этого механизма может показаться кому-то слишком большим, но это действительно уникальная в своей полезности (из личного опыта, в том числе) штука для анализа программных проблем, от простейших до самых сложных


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

Пример 1 - сладкая парочка lockstat/plockstat в том виде, как это работает в 10-м солярисе - почти всегда следующий шаг после анализа результатов работы *stat-утилит (vmstat, mpstat и т.д.). 5 секунд работы, 10 секунд анализа - и почти сразу понятно, в каком направлении копать дальше (иногда и сразу понятна проблема). lockstat и plockstat реализованы посредством DTrace.
Пример 2 - например, такая задача была недавно - некий системный вызов иногда (1 раз в несколько минут) работает недопустимо долго (несколько секунд). Нужно выцепить несколько таких случаев, для каждого из них получить стек вызовов в приложениях (проблема проявляется в разных приложениях) и в ядре (а сисколл один такой медленный), разобраться, какие аргументы передаются каждой из функций ядра, и какая (или какие) функции ядра выполняются слишком долго или слишком часто, вызывая высокое время работы несчастного сисколла. Система немаленькая, каждую секунду - несколько десятков тысяч разных системных вызовов, процентов 5 из них - интересующий нас. Останавливать/сильно замедлять на время анализа систему нельзя. Решено скриптиком строк на 20. Общий результат - проблема решена: проблема в VM, неудачное сочетание 3 багов (один в ядре) и двух фичей.
Пример 3 - вот тут с месяц назад был топик , автор хотел узнать распределение дискового I/O по процессам - сколько и как каждый процесс дёргает диск. При помощи, считай, стандартных (де-факто) скриптов из DTraceToolkit дисковые дела можно разобрать вплоть до единичного перемещения блока головок диска. См., например, seeksize.d, bitesize.d, iofile.d и т.д.
Пример 4 - весь означенный DTraceToolkit вообще стоит внимательно изучить, он написан практиками для решения практических повседневных проблем, в том числе таких, к решению которых традиционными средствами даже непонятно, как подступиться и на которые по этой причине кастомеры иногда просто забивают :)
Пример 5 - там же показано, почему truss (AKA strace/tusc в других системах) есть штука не всегда помогающая и дающая ненулевой импакт на работу системы.

Разумеется, многое можно решить, например, прицепившись дебаггером, наставив брейкпоинтов и т.п. Но это очень и очень непростая, трудно автоматизируемая и мешающая нормальной работе приложения (или ядра) задача. DTrace же позволяет получить ответы на свои вопросы очень оперативно и с минимальными трудозатратами. Спору нет, сам по себе язык D достаточно своеобразен, но, по личному опыту, просто надо начать писать самому хоть что-то и понимание и умение за 5 минут написать нужный код приходит быстро. Он не сложный, просто не очень приятный при наличии опыта с традиционными языками типа C :)

мнениеА о чём говорит SIGBUS? И как самостоятельно можно коре-файлы анализировать - инструментов и методики не знаю.

http://en.wikipedia.org/wiki/SIGBUS

анализировать - ну, например, при помощи любимого дебаггера. Если оракле на 7445 отложил трассировочный файл, лучше начать с него, там, в общем, всё то же самое есть. Если это сложно и непонятно, лучше обратиться в саппорт оракла, там есть специально обученные люди :)

ЯрискаВсе это верно и хорошо расписано. Жаль, что не отражены перспективы всего этого. Хотелось бы услышать мнение автора.

Перспективы чего именно интересуют? Не понял реплику.

очень серыйScott Tiger, хочу вам провокационный вопрос задать :)

Вы довольно вкусно описали преимущества Solaris, но поскольку вы видимо хороший специалист, то по идее можете видеть общую картину, поэтому хотелось бы услышать чем, по вашему, Linux лучше Solaris?

Для продуктивных сред я не вижу ни одного преимущества, кроме, пожалуй, отсутствия Oracle 11g для Solaris x86/64 - это реальный минус, хотя я бы не рискнул 11-й оракле рекомендовать в продуктив :). Можно найти и другие нужные приложения, если постараться - такая проблема есть, но она решается, т.к. Sun заинтересован в расширении доли Solaris на x86/64 (ещё бы! :)). Также возможна ситуация, когда какой-то специфичный софт пишется под единственную платформу, и пользователю не остаётся особого выбора. В качестве такой платформы может выступать и линакс. Это не удивительно, учитывая ту истерию, которая поднималась лет 5-7 назад, когда линакс стали активно и за дело, в общем-то, пиарить, а Sun избрал признанную позже неверной стратегию борьбы путём, что ли, окукливания в спарковой платформе. Факт - про линакс знают даже бухгалтеры. Но crowd, в основном, пишет софт, не ориентированный на промышленное использование.

Обычно к солярке предъявляются следующие претензии:

1. Поддержка меньшего количества оборудования - факт, но сложно представить промышленную систему на "серых" писюках. Плюс активно расширяется список поддерживаемого железа, в т.ч. и за счёт сторонних разработчиков.
2. Сложности с поиском обслуживающего персонала - ложь, найти толкового админа на Solaris ничуть не сложнее, чем на линакс или венду. Просто найти толкового админа вообще сложно :). В силу популярности линакса в массах найти бестолкового админа на линакс куда как проще, чем на солярку. На другие юниксы в ряде регионов найти хоть какого-нибудь админа или сложно или вообще нельзя.
3. Закрытые исходники - полуправда, открыты исходники OpenSolaris. Паталогический бред относительно того, что это не GPL опустим - я пока не знаю случаев, когда это кому-то реально надо, а не просто прихоть.
4. Проблемы с документацией - ложь. Вся мыслимая документация присутствует на http://docs.sun.com Да, для Solaris характерен более академический стиль изложения, а не пачка писанных студентами HOWTO, т.е. инструкций по кликанью мышкой. Но если кто-то собирается действительно изучать систему, а не нахвататься по верхам, такой стиль изложения ему подойдёт более.
5. Меньшее в количественном смысле коммьюнити - факт, за счёт качества. Вероятность получить бестолковый или вредный совет куда меньше.

Для дома для семьи, вообще для случаев, когда проблему проще решить переустановкой ОС или покупкой нового компа, возможно, линакс более предпочтителен.

x86/x86_64Да, просьба, отдельно хотелось бы получить мнение о сравнении на x86 и x86_64

Я не вижу принципиального отличия между этими платформами с точки зрения кода ОС. Платформоспецифичного кода в Solaris очень немного. С линаксом достаточно подробно не ковырялся, не могу сказать.

Чего-то я с запятыми накосячил в предыдущем посте, сорри :)

Есть рыба-пила и есть рыба-молот. Вот только не понятно, что они там строят...

Яриска Scott Tiger ЯрискаВсе это верно и хорошо расписано. Жаль, что не отражены перспективы всего этого. Хотелось бы услышать мнение автора.

Перспективы чего именно интересуют? Не понял реплику.

Интересует мнение относительно перспектив коммерческих юниксов, Solaris например, учитывая, что Linux их теснит, заказчики хотят переходить на "стандартную" архитектуру серверов, да и ORACLE, поговаривают, будут делать порт только на Linux x86-64, а остальные типа "в режиме эмуляции".

Насколько я знаю, Oracle написан на чём-то вроде макроязыка, транслируемого в платформоспецифичный C-код, который уже, в свою очередь, компилируется. Во всяком случае, что-то такое пробегало в оракловом форуме, сейчас найти не могу... Да и кто им даст уходить с больших железок - при всех прелестях x86, более чем 8-сокетных машин стандартной архитектуры пока что нет и не планируется (я не говорю про unisys-овское железо, которое стоит дороже всех спарков вместе взятых). Хотя, конечно, Оракл пеарит свой, как всегда, анбрейкабл линакс, куда деваться :) Это всё маркетинговые заявления, имхо.

ЯрискаКонечно, многое преувеличено, большие системы никуда не делись, Linux-а там нет, однако направление развития настораживает. Желание резать косты велико, да и есть что резать - сервера по миллиону с лишним, и саппорт недешев.

А нет пока вариантов особо. Есть масса задач, где производительности целикового E25K не хватает, под тем же Oracle, и эти задачи никак не ложатся на кластер из писюков. Стоимость сопровождения Solaris не выше, чем стоимость сопровождения Linux на том же техническом уровне. Да, есть люди, которые сознательно поручают админить продуктивные железки зелёным студентам за копейки, но эти люди и проблемы такие огребают, что и в кошмаре не приснятся.

ЯрискаВаше утверждение, что 20 лет развития во многом дают фору может, увы, никак не повлиять на развитие ситуации в перспективе. Вы же не будете отрицать, что в прошлом были такие ОС, в одной из которых давно была и виртуализация, и защита пространств памяти процессов, и встроенная кластеризация, и rolling update и прочее, что ныне порой выдается за новые открытия. И где сейчас эта система, куда завели господа бизнесмены? C Solaris это может и не повториться, но, согласитесь, Sun это типичная коньюнктурно-коммерческая организация, так что кто знает.

Я технический специалист, в маркетинговые дела не лезу :) История знает немало случаев, когда технически прекрасные инженерные решения в коммерческом смысле проигрывали абсолютным уродам. К тому же, в эволюционном смысле развитие нынешнего IT практически закончилось, но продажи стимулировать надо, вот и достают вендоры из загашников запылившиеся никому не нужные ранее идеи и развивают их в меру своих умений. Каждые пару-тройку лет появляется новое модное направление, в которое все стремительно бросаются. В начале века этим был линакс, последние пару лет самая актуальная тема - виртуализация, чего ещё будет через несколько лет - не знаю, наверное, правильные кластеры (вот и инфинибанд резко подешевел неспроста явно :)) Что-то приживается, что-то - нет, по всякому бывает. Модная в железе тема блейдов, думаю, приживётся, возможно, лет через несколько, с развитием кластеризации, будет ещё одно интересное под-направление.

ЯрискаВспомните метания, то был Solaris x86 и даже Oracle 8, то потом его не стало, потом воскрес...

Было дело... Эйфория от бума доткомов, на котором Sun очень круто когда-то выехал - штука опасная, а когда этот рынок рухнул, многие сильно переживали и принимали неверные решения :)

ЯрискаМожет немного сумбурно, но вобщем такие мысли. Что скажите?
А вообще спасибо за ответ выше, интересно было читать про DTrace. Придется изучить тему поподробнее...

Могу только приветствовать такие начинания. Кстати, в опенсолярисе эта тема активно развивается, недавно сделали провайдер для шелл-скриптов :) Соответственно, через какое-то время это уйдёт и в "большой" Solaris.

С0ВЕСТЬПростите за вопрос,
но чем особенно обычная солярка отличается от ОпенСолярки ?
Чем особенным отличаются системы?
ОпенСолярка = Линукс ?

... и все-таки я тебя загрызу... ©

Технически сейчас OpenSolaris - это самый свежий код, в том числе и сторонний (написанный не-сановскими девелоперами), а Solaris - стабильная версия, в которую постепенно включается код OpenSolaris-а.

С0ВЕСТЬ Scott Tiger С0ВЕСТЬПростите за вопрос,
но чем особенно обычная солярка отличается от ОпенСолярки ?
Чем особенным отличаются системы?
ОпенСолярка = Линукс ?

... и все-таки я тебя загрызу... ©

Технически сейчас OpenSolaris - это самый свежий код, в том числе и сторонний (написанный не-сановскими девелоперами), а Solaris - стабильная версия, в которую постепенно включается код OpenSolaris-а.т. е. в будущем будут обьеденены обе системы в одну, или они разностно будут развиваться?
открытую солярку в продакшене используют под оракуля?

Релиз Solaris 11 обещают сделать на базе OpenSolaris-а. Открытую солярку в продакшн я бы не стал рекомендовать, хотя, в принципе, для неё можно даже купить коммерческую поддержку . Но это по определению менее стабильная версия. Информации, использует кто-либо или не использует, у меня нет.