Oracle: OpenSolaris pokračuje, ne vše bude open source (diskuse)

[xm]

Některé "enterprise" vlastnosti však nebude vydávat jako open source.

Takže ho vlastně efektivně zabili Respektive zarazili další hřebíček do rakve

[JoHnY2]

Bude zalezet co vsechno zavrou. Neni mi uplne jasny ceho chce Oracle docilit. Osekavanim funkcionality lidi nedonuti pouzivat Solarko misto OpenSolarka ... Maximalne si nasere stavajici uzivatele a donuti je prejit na linux. Leda ze by jim na tom bezel Oracle, tam uz se pak cena nejakyho Solarisu ztrati

[Milan Jurik]

There may be some things we choose not to open source going forward, similar to how MySQL manages certain value add at the top of the stack,

Kde jsme ho zabili?

[xvasek]

Obávám se, že Solarisu ve větším rozšíření už nepomůže ani masivní letáková kampaň. Všechny tady tyto proklamace ho posouvají jenom dál a dál do ústraní, až na to nakonec Oracle řekne, že to nikdo nepoužívá a tudíž to nebudou dál podporovat. Mezi MySQL a Solarisem je v dnešní době ten zásadní rozdíl, že jednomu z nich neustále klesá uživatelská základna a nějaký impuls pro zlepšení není ani v dlouhodobějším výhledu vidět...

[thingie]

Wtf. Cože. Zprávička je o OpenSolarisu, se Solarisem Oracle asi docela počítá, podle všech vyjádření. A MySQL jde do háje zelenýho akorát, mnohem rychlejš (no, taky na to má prostor, z bývalých výšin slávy).

[Milan Jurik]

Z ceho usuzujete, ze klesa uzivatelska zakladna? Z toho, ze vsechny ty miliony instalaci Solarisu 7 ci 8 nejsou upgradovany na Solaris 10 ci OpenSolaris? To je fakt. SUN probendil svou pozici z roku 2000. Ovsem to, ze by se snizovalo mnozstvi zakazniku, to uz zase pravda neni, ac konkurence tvrdi opak. Stale napriklad plati, ze v high-end je to nejvice prodavany system a to i v minulem roce, ktery nebyl rozhodne prijemny. A migrace na Solaris (i z Linuxu) kvuli ruznym ficuram sleduju docela casto (nepochybne probihaji obousmerne).

Krome toho Oracle Solaris potrebuje pro dve oblasti - SPARC a Storage (stavene nad x86). Dve klicove, kvuli kterych zaplatil za SUN miliardy dolaru. Cekate, ze je LarryE jen tak hodi oknem? Nepodcenujte Oracle.

Navic, odkud by Linux bral inspiraci pro nove ficury?

Verim, ze z pohledu lidi mimo Solaris komunitu vypada OpenSolaris jako neco maleho a nezajimaveho. Jenze vzpomente si na dobu pred 5 lety, kdy byl Solaris na dne. Temer nikdo o nem nepsal, nikdo jej neresil a otevreni kodu se bralo jako zaverecna tecka. Trosku rozdil dnes, ne? Oracle chvili mlci a vyhodnocuje, jak to dal bude resit a hned velka vlna spekulaci (o FUDovani od konkurence ani nemluve). Prani otcem myslenky?

A jinak, tohle je ciste muj osobni nazor, ktery se nemusi nijak slucovat s nazorem meho zamestnavatele.

[xm]

Před těmi 5 lety, kdy došlo k uvolnění OpenSolarisu, se o něm mluvilo a psalo podstatně víc (nebo minimálně já jsem to tedy víc vnímal). Z mého pohledu mi přijde, že zájem o OpenSolaris od té doby naopak uvadl.

[Milan Jurik]

Nebude to spise tvymi neustalymi komentari k ZFS? Vim, ze Google Trends moc nerikaji, ale http://www.google.com/trends?q=opensolaris

[xm]

Co s tím mají co dělat moje komentáře k ZFS? To že mi je OpenSolaris nesympatický kvůli licenci neznamená, že zprávy o něm nějak vyfiltruji Právě naopak (podle hesla poznej svého nepřítele ).

Je ovšem možné, že prostě na webech které sleduji (převážně weby okolo Linuxu a Free software) se o něm píše méně než tenkrát.

[Milan Jurik]

Co s tím mají co dělat moje komentáře k ZFS? To že mi je OpenSolaris nesympatický kvůli licenci neznamená, že zprávy o něm nějak vyfiltruji Právě naopak (podle hesla poznej svého nepřítele ).

Urcite nefiltrujes, jen mozna mene vnimas Neprijde ti divne mit za nepritele system, ktery je inspiraci pro ten tvuj milovany?

Je ovšem možné, že prostě na webech které sleduji (převážně weby okolo Linuxu a Free software) se o něm píše méně než tenkrát.

Mozna proto, ze aktualne se celkem projekty "copy Solaris" rozvijeji slusne - OpenVZ, btrfs, SystemTap (a jine simulace DTrace). Ted bude treba zacit evaluovat Crossbow a COMSTAR (pravdepodobne i dalsi, ale tyhle dva aktualne me napadaji). A pravda, nekonecny problem se skalovanim na SMP/CMT, njn...

A opet, muj soukromy nazor atd...

[jahor]

milane pozor... nekdy by mohly byt nektere veci drive nez na solarisu/opensolarisu... narazim naprikald na Tvou zminku o OpenVZ. pocitam ze ho beres jako klon zon, ale jednak je tu openvz pomerne hodne dlouho, jeste drive tu byl nejspis linux-vserver a obecny chroot ani nepocitam (oboji je "chroot on steroids") samozrejme stranka managementu zon na solarisu je hodne napred pred linuxovymi variantami. co mozna jde trosku po vzoru solarisu jsou linuxove kontejnery. bsd jaily tady take jsou davne roky.

s btrfs ktery by konecne mohl na linux prinest funcionality bezne pouzivane u zfs a nepouzitelne v pripade linuxoveho lvm (vice snapshotu, vliv na vikon apod). ale co jsem pochytil tak jiz drive tu byl filesystem na linuxu ktery hodne tech veci umel, ale diky licencnimu zablokovani byl stazen. i sun mel problem se zfs, ktery ani nevim jakym zpusobem presne skoncil (spor tusim s netapp).

samozrejme je mnoho veci ktere by mely linuxove prostredi inspirovat (pri nejmensim alespon urcita konzistence, man pages apod) a naopak veci ktere si muze vzit k dobu opensolaris (a take si je bere a nekdy az moc - krok ke gnu nastrojum lze povazovat za dosti sporadicky i kdyz mne osobne spis boli zvykani si naopak na standardni solarisi tooly a jejich prepinace)

[Milan Jurik]

Ahoj Jahore O stari linux-vserveru vim (chroot take nepocitam, to je letita zalezitost, ktera nema nic spolecneho s tim, jak funguji zony) a ano, souhlas, ten zakladni koncept prisel nezavisle na kontejnerech ze Solarisu. Ovsem to, ze OpenVZ vicemene prebralo stafetu je realita a to, ze zony jsou napred (dusledek cistejsiho konceptu jadra Solarisu?), take (coz je to, co jsem psal). Inspiraci OpenVZ ma tedy odkud prebirat.

O fs Tux2 jsem slysel, videl e-maily a to bylo tak vse. Ano, WAFL je starsi nez ZFS a Tux2 take (pokud skutecne existoval). Ale ZFS prave neni jen o COW

Vzdy tu bylo neco drive (stale jeste zijeme z toho, co IBM udelalo v OS/360), ale vetsina velkych projektu (vyjimky se najdou, o tom zadna), do Linuxu prisla inspiraci odjinud. Ne nadarmo, kdyz na LKML probihala debata, co Linux prinesl noveho, tak Alan Cox zahlasil, ze vi o jedne veci - unload kernel modulu (load do beziciho systemu je ze SunOSu, unload prisel do Solarisu pozdeji nez byl v Linuxu).

[Yenya]

Jeste upozornuju, ze BTRFS a ZFS - i kdyz navenek poskytuji podobne vlastnosti - jsou interne uplne o necem jinem: ZFS ma strukturu podobnou jako SLAB alokator, akorat pro diskove bloky, zatimco BTRFS pouziva snapshotovatelne B-stromy. Urcite o nejakem kopirovani nemuze byt rec.

Nejaky pokec o tom je tady: http://lwn.net/Articles/342892/ (od byvale programatorky z tymu ZFS).

Udajne kopirovani Solarisu Linuxem je 1000x opakovana mantra, ktera se ale proto jeste nestane pravdivou. Treba v poslednich verzich OSOL je konecne v $PATH driv /usr/gnu pred /usr/bin. A jsou dalsi veci ktere OSOL nema a dlouho mit nebude (networking: IPVS, Netfilter-like zpracovani packetu, large routing tables, I/O schedulery, atd.).

-Yenya

[Hlípa]

Treba v poslednich verzich OSOL je konecne v $PATH driv /usr/gnu pred /usr/bin.

Jmenovat toto jako super vlastnost prevzatou z Linuxu je trochu zcestne. Prvni vec co rozumny clovek udela je, ze si to /usr/gnu vyhodi. Napriklad chmod, chown a podobne gnu nastroje neumi pracovat s rozsirenimy solarisu, takze ztracite funkcnost oproti tem nastrojum, ktere jsou v /usr/bin. Je samozrejmne par commandu, u kterych minimalne ja preferuju gnu a tim je grep a find. U zbytku jsem nepotreboval gnu variantu. Navic lze tyto gnu tooly poustet pomoci ggrep a gfind z /usr/bin.

[Yenya]

O tom asi nema cenu diskutovat z pozice nekoho, kdo je zvykly na Solarisove utility (coz jsou zamestnanci Sunu - jak je videt z teto diskuse - ale zdaleka ne zakaznici Sunu). Muj zamer nebyl presvedcit Vas osobne, ze mate pouzivat GNU utility. Reagoval jsem na poznamky typu "Linux jen kopiruje Solaris", coz neni pravda.

Jednak na prevzeti zajimavych novych myslenek neni nic spatneho (takto se treba do SysV dostalo vi(1) nebo do BSD mandatory locking nebo do vetsiny UNIXu Solarisovy PAM), a jednak v mnoha smerech je to Linux, kdo urcuje smer vyvoje (a Solaris to muze zkopirovat, na cemz nevidim nic spatneho). GNU userland byl jen jeden z mnoha prikladu. Dalsi jsou treba SHA-512 hesla, dnesni podoba PAM, sendfile(2) puvodne vymyslene ve FreeBSD, a tak podobne.

Ohledne GNU userlandu: Jde o spoustu malych vylepseni, ktera urcite jednotlive smetete ze stolu jako nepodstatna, ale dohromady je pocit ze Solarisoveho userlandu takovy, ze porad zakopavate o nejake veci ktere davno povazujete za samozrejme. I kdyz jiste (zatim) nejsou soucasti SUS.

Nedavno jsem treba narazil na neexistenci flock(1) a locate(1). Nebo implicitni pouzivani more(1) pro prohlizeni manualovych stranek: more(1) nerozumi terminalovym klavesam typu Page Up/Down, nepodbarvuje vyhledane retezce, atd. cp(1) neumi delat hard-linky misto kopie ("cp -lr" v GNU coreutils).

-Yenya

[Milan Jurik]

Mno, ZFS vs. SLAB ani tak ne, pro pametovou spravu ARC. Rozhodne to neni promitnuti SLABu na disk Ano, BTRFS uziva moderni algoritmy nad B-stromy, ktere v dobe designu ZFS neexistovaly a to je skutecne prinost BTRFS. Ovsem vlastnosti BTRFS prebira podle ZFS, celou dobu je tak prezentovane. A jinak dnes vyvoj BTRFS a ZFS probiha v te same firme, bude zajimave sledovat dalsi vyvoj

Text Valerie Aurory velmi dobre znam, vcetne ceske verze tady na ABClinuxu. Je poznat, ze Valerie odsla z tymu ZFS velice brzy na pocatku vyvoje.

Mate pravdu, pro sitovou vrstvu ma Linux rozhodne sadu technologii, ktere od Solarisu neprebral (a naopak tam Solaris ma co dohanet, aspon, ze zvladl srovnat krok co se tyce performance pred casem, i kdyz to vedlo k odumirani streams). K tem I/O schedulerum - kdyby opravdu poradne fungovaly, tak jsem je tu v predchozim prispevku nezminoval.

A to GNU v PATH bych radsi nekomentoval, staci, kdyz to kritizuji dost halasne uvnitr firmy. Hlipuv komentar k tomu je asi dostatecne vystizny.

[xvasek]

Když už jsme u těch Google trends, tak proč se nepodívat taky na Solaris a nesrovnat s Opensolaris: tady. Pravda je, že musím ještě přiznat svou chybu u MySQL, protože tam to taky na žádný pozitivní vývoj nevypadá...

[Milan Jurik]

Google Trends asi moc nefunguje pro dlouhodoba keywords, viz linux

http://www.google.com/trends?q=linux&ctab=0&geo=all&date=all&sort=0

Mnozstevni porovnani asi plati a tam samozrejme Linux buzz funguje radove lepe, coz nepopiram

[Ivan]

+ byly doby kdy byl Solaris primarni vyvojova platforma pro Oracle DB.

[..... Izak .....]

Dnes je to linux.

nekolik duvodu: * x86 HW je vykonnejsi nez SPARC a pokud ma byt sparc stejne vykonny, tak stoji o rad i vice vice, diky drahemu HW. * linux je kvalitni OS a i kdyz toho umi solaris mnoho, vse je takove divne a tezkopadne, uz jenom, kolik zerou zony proti podobnym tech. v linuxu. * Solaris moc lidi neumi a je to prave proto, ze az umi kupu veci, vcetne advanced prav, tak je tam vse malem zdvojene a je v tom bordel, ani sluzby to neumi startovat/stopovat jenim systemem, jen ja tam znam z hlavy 3 .... umi to snapshoty, sw raid ... ale dokud nebyl ZFS, tak kazdy radeji sahl po veritas vol. manager a vfs

* linux jiz nema problem s masivnim I/O a tisici procesy ci thready, je to diky kernelu 2.6, ma journal FS, ktery Solarisu chybel a ma pokrocily clustrovaci FS, na kterem ted oracle stavi svuj jako ze vlastni No a tim, ze je linux moderni OS, tak se pro nej lepe pisi aplikace i moduly, diky tomu, ze se hledelo na cistotu jak kodu, tak api, je mozno davat do kernelu rozumne nove fce .... a v gcc pouzivat moderni metody programovani .... No a solaris na x86 nebezi, je na ni nasilne nasazen a neni to v zdanem pripade tak dobre, jako na SPRACu, tedy tak leda pro testovani a vetsina programu ani x86 solaris nepodporuje ... tedy oracle ano, ale nikde jsem jej nevidel bezet jinak, nez jako testovaci DB, zatimco na linuxu to nasazuje kde kdo.

[Milan Jurik]

x86 HW je vykonnejsi nez SPARC? Fakt? Jak pro co. Ja jen, ze ty nejvykonnejsi db systemy jsou SPARC based. Duvody proc je to dnes Linux (cca poslednich 5 let) byly trosku jinde A jinak Solaris neni SPARC only cca 20 let

ani sluzby to neumi startovat/stopovat jenim systemem, jen ja tam znam z hlavy 3

Eh? Do S9 skrze init skripty, od S10 skrze SMF?

linux jiz nema problem s masivnim I/O a tisici procesy ci thready

Fakt? Hmmm a kdy konecne bude mit uzitelny schedulery (I/O a CPU)? To skalovani je fakt stale tezka bida na velkych SMP systemech. Ac se musi nechat, ze hlavne Intel se ted hodne snazi.

ma journal FS, ktery Solarisu chybel

Heh? UFS v Solarisu je zurnalovaci uz nejaky ten patek (dost davny patek)

No a solaris na x86 nebezi, je na ni nasilne nasazen a neni to v zdanem pripade tak dobre, jako na SPRACu, tedy tak leda pro testovani a vetsina programu ani x86 solaris nepodporuje ...

Co je tohle za blabol? Nasilne nasazen? Ten code base je vyvijen spolu se SPARC verzi cca stejne dlouho jako Linux je na svete. To, ze Solaris 9 x86 verze vysla se spozdenim (a puvodne vyjit nemela), nic nemeni na tom, ze se kod udrzoval i v te dobe. Ano, protoze SUN udelal tu kravinu, ze x86 vetev po jisty cas nevyvijel, tak ISV k teto vetvi meli dost neduveru.

S nekterymi komentari souhlasim, treba okolo Veritasu. Ale s tou cistotou API jste me pobavil. O tom, jak GCC umoznuje na Linuxu uzivat moderni metody programovani, by bylo take zahodne se rozepsat.

A opet standardni disclaimer o tom, ze je to pouze muj soukromy nazor...

[Yenya]

x86 HW je vykonnejsi nez SPARC? Fakt? Jak pro co. Ja jen, ze ty nejvykonnejsi db systemy jsou SPARC based.

Mate pro to nejake citace? Ja jsem myslel ze nejvykonnejsi byvaji IBM. My treba mame nejvetsi databazovy server SGI proste proto, ze nikdo nebyl pred temi dvema lety schopen dodat vic nez 16 socketu (i Sun koncil na 16 socketech). Jediny kdo jeste krome SGI vyrabel vetsi zelezo byla IBM, ale ti to meli extremne drahe a nebylo jasne, jestli si tim pomuzeme.

A jinak Solaris neni SPARC only cca 20 let

S prestavkou asi 10 let, ze? Jednou jsem instaloval Solaris x86 (cca 1999, jestli si pamatuju) a byla to bida - fungovat zacala az asi treti sitova karta kterou jsem zkusil pouzit.

linux jiz nema problem s masivnim I/O a tisici procesy ci thready

Fakt? Hmmm a kdy konecne bude mit uzitelny schedulery (I/O a CPU)? To skalovani je fakt stale tezka bida na velkych SMP systemech.

Zkousel jste se nekdy v poslednich letech divat na top500.org? Ja si nemyslim ze skalovani Linuxu na 16384 procesorech by byla "tezka bida". Samozrejme, interne si muzeme rict ze by to mohlo byt lepsi (SGI taky standardne dodava 1024-procesorove bloky ze kterych se pak uz stavi klastry na aplikacni urovni), ale ve srovnani se Solarisem jde o zanedbatelne problemy. Solaris jsem nevidel nikdy jet na vic nez 16 socketech (pochybuju ze se kdy delal HW pro Solaris vetsi nez 128 socketu).

-Yenya

[Milan Jurik]

x86 HW je vykonnejsi nez SPARC? Fakt? Jak pro co. Ja jen, ze ty nejvykonnejsi db systemy jsou SPARC based.

Mate pro to nejake citace? Ja jsem myslel ze nejvykonnejsi byvaji IBM. My treba mame nejvetsi databazovy server SGI proste proto, ze nikdo nebyl pred temi dvema lety schopen dodat vic nez 16 socketu (i Sun koncil na 16 socketech). Jediny kdo jeste krome SGI vyrabel vetsi zelezo byla IBM, ale ti to meli extremne drahe a nebylo jasne, jestli si tim pomuzeme.

Staci si projit benchmarky, ktere Oracle zacal releasovat. Nebo vyhodnocovani TPC (viz ten zabavy TPC-C test z podzimu). Protoze IBM Power jako samostatny megabox je slusna vec, az na propustnost (s tou slusny hybli v Power7) a nenazranost. Seznam zakazniku vam poskytnout nemohu, takze se omlouvam a muzete me obvinit ze lzi Take doba se trosku posunula za ty 2 roky, pocitat server pro databaze podle poctu socketu, je trosku divna kalkulace (ale to byla asi vzdy).

A jinak Solaris neni SPARC only cca 20 let

S prestavkou asi 10 let, ze? Jednou jsem instaloval Solaris x86 (cca 1999, jestli si pamatuju) a byla to bida - fungovat zacala az asi treti sitova karta kterou jsem zkusil pouzit.

Solaris 8 a Solaris 10 rozhodne nedelilo 10 let (rok 2000 a 2005 kdyz vezmeme release data). Ano, Solaris 8 sel instalovat na subset x86 stroju. Tak jako Linux v roce 1999.

linux jiz nema problem s masivnim I/O a tisici procesy ci thready

Fakt? Hmmm a kdy konecne bude mit uzitelny schedulery (I/O a CPU)? To skalovani je fakt stale tezka bida na velkych SMP systemech.

Zkousel jste se nekdy v poslednich letech divat na top500.org?

Dival. A? Co vypodiva cluster stroju o skalovani na SMP strojich?

Ja si nemyslim ze skalovani Linuxu na 16384 procesorech by byla "tezka bida". Samozrejme, interne si muzeme rict ze by to mohlo byt lepsi (SGI taky standardne dodava 1024-procesorove bloky ze kterych se pak uz stavi klastry na aplikacni urovni), ale ve srovnani se Solarisem jde o zanedbatelne problemy. Solaris jsem nevidel nikdy jet na vic nez 16 socketech (pochybuju ze se kdy delal HW pro Solaris vetsi nez 128 socketu).

-Yenya

A s vyrovnanou zatezi? Rozjet je kde co mozne, ale to neznamena, ze to je dobre vytizene. Kde jsou vysledky testu mimo exhibici v TOP500, nahnane rozlozenim zateze na mnoho nodes? V TOP500 jsou stroje s "nejrychlejsim prubehem smyckou" pro vedecke vypocty. Trosku jina zatez nez databaze, nemyslite? Jinak M9000 ma 256 jader (64 socketu pro quadcores). To ovsem neni limit Solarisu. A standardni disclaimer o mem osobni nazoru...

[Radim Kolář]

Ten TCP-C z podzimu vyhral Solac jen kvuli SDD diskum a navic Oracle podvadel pri cenach za licence. POWER7 s DB2 9.8 PureScale a SDD diskama posle Oracle zpet do haje - videl jsem jejich testovaci benchmarky.

[Yenya]

Staci si projit benchmarky, ktere Oracle zacal releasovat.

Sorry, ja neunderstanduju language vaseho tribe [nic osobniho, ale tohle mi fakt nedalo, omlouvam se predem ;-]

pocitat server pro databaze podle poctu socketu, je trosku divna kalkulace (ale to byla asi vzdy).

Bohuzel ale pocitat server pro _nasi_ databazi podle databazovych benchmarku nekoho uplne jineho je taky divna kalkulace. Zejmena pro ty ruzne TPC, ktere jsou typicky hodne malych a dost podobnych operaci nad relativne malym mnozstvim velkyhch tabulek (simulace OLTP a podobne). My jsme tehdy pro odhad hrubeho vykonu zeleza (vcetne toho jak je to skalovatelne) pocitali SpecInt a SpecINT rate. A tam tehdy Sun stal fakt za houby proti tehdejsimu SGI (nehlede na to, ze SGI nam pak ve vyberovem rizeni nabidli stroj s vyrazne vetsim poctem procesoru).

Ano, Solaris 8 sel instalovat na subset x86 stroju. Tak jako Linux v roce 1999.

Jiste muzete jak 10 % vsech stroju, tak i 99 % vsech stroju nazvat "subset" a tvarit se ze je to vlastne totez. Zni mi to ale fakt divne.

Co vypodiva cluster stroju o skalovani na SMP strojich?

Cluster 16 stroju o 1024 socketech vypovida o skalovani aspon to, ze na 1024 socketech je ten system pouzitelny i jako single-image.

Kdyz uz teda slovickarime: skalovatelnost SMP stroju konci na cca ctyrech, s bidou osmi socketech. Vse co je nad to je budto NUMA, nebo je to pomale.

Kde jsou vysledky testu mimo exhibici v TOP500, nahnane rozlozenim zateze na mnoho nodes? V TOP500 jsou stroje s "nejrychlejsim prubehem smyckou" pro vedecke vypocty. Trosku jina zatez nez databaze, nemyslite?

Pokud se bavime o skalovatelnosti, tak prece tam _jde_ o to rozlozit zatez na vice procesoru, ne? Nehlede teda na to, ze SPARC VII ani T2 nijak neexceluji ani v jednoprocesorovem vykonu. To uz jsme ale dal od operacnich systemu.

Prijde mi fakt divne jedno mereni shodit ze stolu jako "exhibici" a jine mereni (TPC-C) prosazovat jako prukazne (zvlast kdyz - jak ctu vedle - slo o "umele nahnany vykon" pouzitim SSD .

-Yenya

[Milan Jurik]

Huh, dobre, sada vykonostnich testu a vy rozhodnete podle SpecInt? Pro databazovy stroj? Pri tak velkem nasazeni je dost obvykle provadet vykonostni testy primo na navrzenem setupu. Takove firmy maji primo prezentacni servrovny (aspon tedy SUN ma), kde se provedou prislusna srovnani a realne vykonnostni testy.

Souhlas, ze exhibice skrze TPC jsou primarne marketingova (a asi i duvod, proc je SUN leta nedelal, jenze zakaznici je casto chteji). Prave proto se ale delaji vyse popsane testy. Nebo si snad myslite, ze si Oracle koupil SPARC, aby stavel reseni na Powerech? Proc by do toho vrazel miliardy dolaru? Ne, fakt si nekupoval SUN jen pro Javu a MySQL.

Co se tyce toho subsetu, rok 1999 si pamatuju primarne na Linuxu na x86, Solaris na x86 existoval, byl vyvojen paralelne, ale tak jako Linux, tak i Solaris nemel vetsinou pristup k dokumentaci perifernich zarizeni. Takze vse koncilo reverznim inzenyrstvim, coz si SUN nemohl dovolit, protoze na to prodaval podporu. Presto tvrzeni, ze Solaris na x86 nebyl 10 let je proste a jednodusse nepravdive.

Co se tyce toho skalovani na 1024 socketech, opet, rozjet lze kde co, ale spravne distribuovat vykon, to hure. Proc v TOP500 dnes vladnou systemy postavene na Linuxu, ma spise duvod v existenci podpory dodavatele clusteru a SW stacku, ktery byl poslednich 10 let na Linuxu prave pro clustery vyvijen. Stale to nic nerika o tom, jak dokaze jadro rozkladat zatez. Navic, Solaris 10 si na cluster pro vedeckotechnicke vypocty nenasadite, OpenSolaris mozna. Casto tam tedy konci Centos, kvuli "supportu zdarma" a proverenemu reseni.

A skalovatelnost systemu vs. skalovatelnost aplikace. Ano, aplikace, jejichz algoritmy dokazi minimalizovat dopad pomalejsich interconnectu v clusteru (sorry za anglictinu, ale neco radsi neprekladam), tolik nevytezi ze SMP. Ale treba aplikace se znacnym konkurencnim pristupem k datovym ulozistim u SMP muze tezit radove vice. Je to ciste o typu nasazeni. Solaris se prave zameril uz pred lety na SMP systemy (za coz mimochodem obetoval i vykonost na jednoprocesorovem systemu). Ano, SPARCVII ani T2 nevladnou hrubou silou na vypocet nekonecne smycky. Jenze to neni jedina cast vykonu systemu, je to take o tom, jakou skutecnou propustnost ma cely system a operacni system nad nim.

Jinak treba ty synteticke testy jsou pekne zde pro Linux vs. Solaris (bohuzel vybrany stroj pro SPARC vs. x86 neni zrovna databazove vhodny):

http://tweakers.net/reviews/649/9/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron-solaris-vs-punt-linux.html

Ano, jsou to synteticke testy a obe strany se je urcite snazily analyzovat za dany cas. Ale jako priklad ukazuji nektere vlastnosti (vcetne v tom clanku jsou pak synteticke testy k starsi Niagare).

Mereni neshazuju ze stolu, ale nemate jedine mereni Solaris vypocetniho clusteru ve stejne konfiguraci, tj. vase porovnani kulha.

A opet, disclaimer, ze je to jen muj osobni nazor a nemusi se slucovat s nazorem meho zamestnavatele (omlouvam se, ale realita je realita).

[Yenya]

Huh, dobre, sada vykonostnich testu a vy rozhodnete podle SpecInt? Pro databazovy stroj?

SpecINT _rate_, nikoliv SpecINT. Ten prvni je docela dobrym odhadem skalovatelnosti hardwaru samotneho, ten druhy je hruby odhad vykonu jednoho CPU. A ano, nase zkusenosti potvrzuji, ze systemy ktere pro nasi databazovou aplikaci kupujeme, se zhruba podle tech SpecINT rate chovaji.

Pri tak velkem nasazeni je dost obvykle provadet vykonostni testy primo na navrzenem setupu. Takove firmy maji primo prezentacni servrovny (aspon tedy SUN ma), kde se provedou prislusna srovnani a realne vykonnostni testy.

Ja chapu ze o nasi aplikaci toho vite vic nez my, ale nase zkusenosti ukazuji, ze nejvetsi zatez kterou resime nejsme rozumne schopni simulovat ani my sami na hardwaru a softwaru ktery mame plne pod kontrolou, natoz z toho zkouset extrahovat nejake synteticke testy. Pro zajimavost - spicka zateze kterou resime se u nas vyskytuje 2x za rok po dobu cca 10-15 minut.

Dalsi problem je, ze do vyberoveho rizeni musite dat jasne kriterium podle ktereho se bude tridit. Urcite nelze verit vyrobcum ze kdyz jim poskytnete svuj vlastni test (i kdybste ho mel, my nemame), ze se nebudou snazit nadehnat vykon nekde kde to zrovna nemate tim testem postihnute (jako ty TPC-C a SSD zminovane vedle v diskusi). Se SpecINT Rate mame dobrou zkusenost, ze je tezke v nem nejakou "oklikou" dosahnout vyrazne lepsich vysledku nez konkurence.

Takze vse koncilo reverznim inzenyrstvim, coz si SUN nemohl dovolit, protoze na to prodaval podporu.

A to je jeden z duvodu, proc Sun dopadl tak jak dopadl. Je to dost lacina vymluva "museli bychom to podporovat", ale ja bych byval tehdy v tom roce 1999 byl rad klidne i za nepodporovany ovladac, nez muset resitt kde sezenu jiny hardware a cim ho zaplatim. Red Hat i Novell/SUSE prodava sve podporovane systemy i s ovladaci vzniklymi reverznim inzenyrstvim (na RHEL5 ted namatkou vidim ovladac forcedeth pro sitove karty NVidia nebo bcm43xx pro WiFi cipsety Broadcom).

Presto tvrzeni, ze Solaris na x86 nebyl 10 let je proste a jednodusse nepravdive.

Tento casovy odhad jsem prehnal, omlouvam se.

Co se tyce toho skalovani na 1024 socketech, opet, rozjet lze kde co, ale spravne distribuovat vykon, to hure.

Prosim nedezinterpretujte me: u SGI _rozjeli_ pocitac se 16384 CPU (single-image), nebylo to uplne skvele, tak prodavaji "jen" 1024 socketove jednotky (asi 2048 CPU). A tyto se realne pouzivaji nejen pro vypocty ale i pro databaze. Teprve pokud chcete vic socketu, muzete si postavit cluster nekolika malo techto 1024-socketovych single-image systemu.

... nevytezi ze SMP ... konkurencnim pristupem k datovym ulozistim u SMP ... zameril uz pred lety na SMP systemy ...

Opet pripominam terminologickou nepresnost: zelezo o kterem se tady bavime rozhodne neni SMP. SMP konci na cca 4 socketech. V podstate kazdy dnesni stroj kde je pametovy radic u procesoru je NUMA. (a teda jeste uplne hnidopisstvi - anglicke slovo "concurrent" se v tomto kontextu nepreklada do cestiny jako "konkurencni", ale jako "paralelni").

Mereni neshazuju ze stolu, ale nemate jedine mereni Solaris vypocetniho clusteru ve stejne konfiguraci, tj. vase porovnani kulha.

Mel jsem za to, ze se nebavime o clusterech, ale o single-image pocitacich. A proc nemam takove mereni? No proto ze Sun zadny stroj s 1024 sockety nedela. Takze bavit se o skalovatelnosti v pripade, kdy se jeden operacni system v praxi pouziva na realne prodavanem zeleze s 1024 sockety a druhy - jak jsme se shodli - nikdo nikdy nevidel na zeleze se 128 sockety fakt nema smysl.

-Yenya

[Milan Jurik]

Z charakteristiky toho stroje (2x za rok spicka po velmi kratkou dobu) bych si tipl, ze se jedna o prihlasovani na predmety, spravu rozvrhu a zkousek (mohu se mylit a ano, vnitrnosti vasi aplikace neznam). Dokazu si predstavit narust te spicky a pak uznavam, ze je velmi tezke takovy konkurecni pristup simulovat, i kdyz se nepochybne delaji. Tezko rici, zda je mimo databazove firmy nekdo provadi v nejake hojne mire (ale obcas se spickove vykony zverejnuji jako soucast nekterych benchmarku). Stale mi prijde podivne ale hodnotit ty stroje podle SPECint (+ rate verze), vzhledem k tomu, ze SPECint neobsahuje zadny uzitecny test pro takovy workload. Ale jinak ano, SPECint2006 rate to misto, kde Altix vladne a stale, i po vice jak 3 letech (a kde, mimochodem, ani certsvy Power 780 neporazil M9000).

Co se tyce toho TPC-C (a nahnani SSD disky), jak jsem uz rekl, souhlas, je to marketing (jak ukazat, ze za nizsi cenu dostanete mnohem vykonnejsi system na mnohem mensim prostoru s vyrazne nizsi spotrebou, coz je dnes hnaci silou velke casti prodeju). To jen k tomu nahoneni skrze SSD disky (hodnoti se cely vykon systemu, ne jen CPU).

Kde jsem vas dezinterpretoval? Pro nektere aplikace jsou dobre, ale to nic nerika o kvalite rozkladani zateze v Linuxu.

OK, beru, jak chapate vy rozlozeni stroju a respektuji. Z tohoto pohledu jsou si M9000 a Altixy asi podobne.

Stale pocitate sockety, to je zlozvyk z licenci databazovych stroju? Souhlas, 2048 CPU threadu proti 512 CPU threadum neni porovnatelne (jinak port Solarisu na Altix pro srovnani skalovani asi opravdu nikdo neudela, otazka financi). Ale to stale nic nerika o tom, jak kvalitne OS skaluje, jak dobre vytezuje srovnatelne stroje. Ta srovnani jste zaignoroval?

+ standardni disclaimer o mem osobnim nazoru...

[Yenya]

SPECint neobsahuje zadny uzitecny test pro takovy workload.

SpecInt rate obsahuje paralelni verze vseho mozneho (napriklad kodovani H.264), kde se projevi jak rychle umite prehazovat radky cache z jednoho CPU na druhy (jinymi slovy, jak rychly umite zkonstruovat mutex/spinlock/zamek). A od toho se odviji skalovatelnost vsech paralelnich aplikaci.

Kde jsem vas dezinterpretoval?

Mel jsem pocit ze se me snazite porad interpretovat tak, jako by 1024-socketovy single-image system ktery prodava SGI bylo neco experimentalniho, co se v praxi nepouziva. Treba jsem Vas jen spatne pochopil.

2048 CPU threadu proti 512 CPU threadum neni porovnatelne ...

Tak ono hlavne neni porovnatelne vlakno implementovane jadrem procesoru s vlastni L1 a L2 cache a vlakno coby paralelizace uvnitr jednoho jadra (SMT/CMT/hyperthreading), ktere s ostatnimi vlakny tehoz jadra o tu L2 cache souperi, a dostane se ke slovu pouze v pripade, kdy zrovna je nejaka vypocetni jednotka volna. A ted budto mate stesti, ze se vsechna takovato vlakna vejdou do L2 cache a fakt vyuzijete vic vypocetnich jednotek ktere procesor ma (a pak zalezi kolik takovych jednotek mate volnych - T2 jich ma hodne, Pentium IV malo), nebo stesti nemate, a misto zvyseni rychlosti se vlakna zacnou navzajem vyhazovat z L2 cache, a vysledek je pomalejsi nez by tomu bylo pri jednom vlakne na jedno jadro procesoru.

Dovedu si predstavit, ze pro nektere ulohy (vsechno jsou vlakna _jednoho_ procesu, dohromady spolu resi jednu ulohu a potrebuji casto komunikovat) je SMT vyhodne. Nebo pak kazde vlakno dela uplne neco jineho a zpracovava hodne dat (ruzne SQL dotazy v Oraclu), a pak muze byt vyhodnejsi SMT vubec nemit.

Ale to stale nic nerika o tom, jak kvalitne OS skaluje, jak dobre vytezuje srovnatelne stroje. Ta srovnani jste zaignoroval?

Nikoliv. Jen moc nemam co bych k tomu rekl, ani jsem poradne nezkoumal co tam delaji, jak moc se toho ucastnil treba filesystem, atd. Nechci tady tvrdit ze v tom benchmarku byly nedostatky, ale na druhe strane jsem nezkoumal jak ten benchmark vlastne fungoval. Na pohled to vypada, ze pokud se vytizily presne vsechny procesory (nebo i o kousek vic), tak byl Linux/MySQL rychlejsi. Vic stejne na databazovem serveru poustet nechcete.

Co je nad to strasne zalezi na tom, jak je ta vec nakonfigurovana (napriklad frekvence casovace, ktera muze dat vyssi interaktivitu, ale v pripade vice nez 100 % zatizeni CPU muze znamenat castejsi vylevani cache po prepnuti kontextu, atd. Tak jako nechci investovat cas do zkoumani konkretniho TPC-C co vede v nejake kategorii, nechci investovat cas ani do zkoumani tohoto.

-Yenya

[Milan Jurik]

Ano, odviji se od toho schopnost systemu vytizit jednotliva CPU pri sdileni dat, stale ale neni adekvatni databazovemu workloadu. Ale co uz, vy jste zakaznik a vy jste urcil sve pozadavky.

Asi jsem se spatne vyjadril k tem velkym Altixum, ja vim, ze existuji a ze existuji i jejich nasazeni, ale proste tak, jak vypadaji a jaky naskok by mely mit podle hrubeho vykonu, to neukazuji ve velke vetsine pripadu. Ciste podle meho.

Jak jste sam charakterizoval, sdilena L2 cache muze a nemusi byt pro CMT systemy vyhodou, ale nepochybne se pro ruzne workloady hodi ruzne typy a nekdy i generace (treba T1 pro databaze byla tezce nevhodna, ale specialne T2+ se posunula dal, i kdyz zakladni struktura neni tolik odlisna). A u toho Oracle DB, az tak snadne to s tim skalovanim Oracle DB asi nebude, ale to uz je uplne jine tema

S MySQL je, co se skalovani tyce, velka potiz, ten graf spise pak ukazuje to, ze Solaris se trochu lepe vyrovnal s pretizenim nez Linux. Chtelo by to kvalitnejsi analyzu, souhlas. Kdyz prochazim verejne informace, tak je vse vyrazne vagni a to z obou stran. Skoda.

"Disclaimer"

[Radim Kolář]

T1/T2 byla mimoradne vhodna pro Oracle a to zejmena diky ultralevnym licencim, ktere se pocitaly per socket a poskytovalo to dobry vykon prakticky zadarmo.

Tedy do doby nez Oracle zmenil u T1/T2 cenovou politiku.

[cthulhu]

(i Sun koncil na 16 socketech)

(pochybuju ze se kdy delal HW pro Solaris vetsi nez 128 socketu).

nesmysl, viz. Sun E25k / M9000.

[Yenya]

(i Sun koncil na 16 socketech)

(pochybuju ze se kdy delal HW pro Solaris vetsi nez 128 socketu).

nesmysl, viz. Sun E25k / M9000.

Bohuzel E25k neznam, na Wikipedii se pise:

The E25K supports up to 72 dual-core UltraSPARC IV+ processors

O M9000 jsem na jine strance nasel

32 or 64× SPARC64 VI or VII

Vim, je to wikipedia, ale fakt se mi nechce investovat cas. V me oblasti vesmiru je jak 72, tak i 64 mensi nez 128. Pokud mate jiny zdroj, prosim odkazte.

-Yenya

[cthulhu]

on je rozdíl mezi 1x socket (8-core, 128 hw threadů) a 1xsocket (např. dual core UltraSPARC IV) - a s SGI to bude tuplem porovnávání hrušek s hruškovicí. asi fakt přemejšlím jinak a v mým vesmíru je dneska počet socketů na single mašině naprosto nezajímavej údaj, protože škálovatelná aplikace se prostě nakonfiguruje do clusteru/RAC o x nodech.

[Yenya]

Rozporoval jste moje tvrzeni o tom, ze se HW pro Solaris nedelal ve vic nez 128-socketovem provedeni. Dolozil jsem ze to tak neni. Proc ted presouvate hovor jinam?

Podle tehdejsich SpecINT rate bylo tehdejsi 2-jaderne Itanium na tom lepe nez tehdejsi UltraSparc (myslim ze VI, ale muzu se mylit). Samozrejme je nesmysl srovnavat tehdejsi Itanium (ktere se od te doby nikam moc neposunulo, patri mu to s dnesnim UltraSparc VII+ nebo Opterony s jadrem Barcelona.

škálovatelná aplikace se prostě nakonfiguruje do clusteru/RAC o x nodech.

Vas optimismus bych chtel mit Podstatna podminka je zde "skalovatelna aplikace". Coz je o dost mensi trida aplikaci pokud uvazujete cluster nez pokud uvazujete single-image NUMA stroj.

Mozna vas zaujme, ze do te prvni tridy nepatri a do druhe patri treba (ted uz vase Oracle Database. A to ani nemusite ten klastr realne vyuzivat: my jsme v testovacim provozu zkouseli jen zalozni server na ktery nesly zadne pozadavky, a v teto konfiguraci i pri pouhem restartu databaze na primarnim serveru byla databaze tak prvni pul hodiny nepouzitelna, nez zjistila, ze fakt ma cenu drzet data v cache jen na primarnim serveru. Prekonfigurovanim databaze bez RAC tento problem zmizel a start databaze je rychly. A kdyz jsme uvazovali jestli koupit jeden velky server nebo treba ctyri 4-socketove, tak nam interne dodavatele HW rekli, ze takto Oracle nikdo nepouziva, protoze je to pomale. Ze jedine vyuziti jsou dva uzly a stand-by databaze, nic jineho realne nefunguje.

-Yenya

[cthulhu]

vše je divné a těžkopádné, protože tomu nerozumíte, nebo pro to jsou nějaké důkazy? Solaris se snaží držet zpětnou kompatibilitu a proto sebou tahá různý "bordel" z minulosti, což je skvělé pro firmy (bez ironie), např. skript napsaný před dvaceti lety na ksh88 pořád funguje, stejně jako na HP-UX/AIX. Zóny jste viděl leda z rychlíku, protože byste jinak věděl, že zóna bez aplikací si vezme řádově desítky MB paměti, CPU overhead je minimální. Některé věci lze dělat více způsoby (resource management, práva atp.), prostě unix. Služby jsou od Solarisu 10 pod SMF a to buď nativně, nebo "legacy", rád bych věděl ten třetí způsob. Každý nerad VxFS/VxVM, vzhledem k tomu, kolik stojí licence a na mnoho implementací je to kanon na vrabce. Asi jste toho ještě hodně neviděl (Oracle na Solaris x86), na zbytek nehodlám reagovat, ..FUD. -

[Andrej]

No a solaris na x86 nebezi, je na ni nasilne nasazen a neni to v zdanem pripade tak dobre, jako na SPRACu, tedy tak leda pro testovani a vetsina programu ani x86 solaris nepodporuje ...

Připomínáte mi jednoho týpka, který v roce 2004 napsal do diskuse o Linuxu: „Linux je na houby.“ A když se ho někdo zeptal, proč si to myslí, odpověděl: „Nechtěl bych systém, který nepodporuje USB a češtinu!“

Vaše tvrzení o „násilném“ nasazení OpenSolarisu na x86 mi tuhle historku připomnělo. Kdybyste ho pronesl kolem roku 1995, možná by dávalo smysl. Podle mě dnes už Solaris „USB a češtinu“ (obrazně řečeno) umí.

[Milan Jurik]

Asi tak nejak. Nekdy me takove komentare prenaseji do let 1996/97, kdy jsem na Linuxu zacinal. Presne takhle reagovala vetsina uzivatelu MS Windows (a je dost mozne, ze i admini Solarisu).

[Andrej]

No právě... Jenže všechna tato jednostranná a nevyvážená srovnání systémů jsou tak trochu přitažená za vlasy.

Nelze nepřipomenout slavnou zprávu, kde Bryan Cantrill na dlouhý výklad Davida S. Millera o tom, že Linuxu na platformě SPARC stačí většinou jen 18 instrukcí k tomu, aby se dostal od trap table k interrupt handleru v C, odpovídá naprosto geniálně: „Have you ever kissed a girl?“

Když člověk dnes nahlédne do Solaris Internals nebo (nejlépe) přímo do uts, zjistí, že trap table a obsluhu přerušení sice dělí mnohem víc než 18 instrukcí, ale zato tam je microstate accounting, několik různých statistik, traptrace... Zkrátka věci, které drží Solaris na světové špičce, pokud jde o observability.

Žabomyší války, kde účastníci tvrdí, že ten či onen názor či přístup k věci je lepší než jiný, jsou většinou plné polopravd všeho druhu.

Téměř všechny výroky ze skupiny „Solaris je horší než Linux“ zpravidla po překladu z jazyka naštvaného začátečníka do češtiny zní „na Solaris nejsem zvyklý, proto ho neumím používat tak dobře jako Linux“.

Dnes má každý z nás na stole stonásobně rychlejší hardware než byl ten, o kterém se hádali Bryan Cantrill a David S. Miller. Když se na dnešní rozepře jednou podíváme s odstupem času, někdo si možná řekne „fajn, byli jsme tenkrát o dvě instrukce rychlejší, but have I ever kissed a girl...?“.