Új hozzászólás Aktív témák

  • bambano

    titán

    Ha egyáltalán nincs operációs rendszer a ketyerében, akkor min fut?

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • shev7

    veterán

    válasz bambano #1 üzenetére

    javan :)

    ''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''

  • bambano

    titán

    válasz shev7 #2 üzenetére

    Khmm. a java az a virtuális gépen fut...

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • shev7

    veterán

    válasz bambano #3 üzenetére

    a virtualis gep meg javan :DDD

    ''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''

  • bambano

    titán

    válasz shev7 #4 üzenetére

    Maradjunk annyiban, hogy ez a szokottnál is gagyibb pr cikk volt :)

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • nyaralasptt

    csendes tag

    válasz bambano #1 üzenetére

    most lehet faszsagot irok /meg talan ildomosabb lenne konkretan utannanezni, mielott osztom az eszt/, de szerintem a VMware ESX illetve maga a futtatokornyezet biztositja azokat az alap oprendszer funkciokat, amik szuksegesek a futashoz. Ezekbol egyebkent valoszinuleg tenyleg nincs tul sok, legalabbis ha valaki szokott java/jvm/ forrast olvasgatni, akkor feltunhet, hogy gyakran igen alacsony szintu funkciok is javaban vannak implementalva /ami a JIT miatt tipikusan nem jelent tul nagy teljesitmenyveszteseget/.

    GITS

  • Eperfa

    tag

    válasz bambano #5 üzenetére

    bár a tendencia valóban ez, maradjunk inkább annyiban h ez egy átgodolatlan fikázás volt [noflame]

    A hardver- és szoftverkörnyezetek összekapcsolását végző hypervisorréteg kialakításához a BEA a VMware ESX szerverét használja fel, mely közvetlenül, operációs rendszer nélkül fut a szervergépen. Az egyes virtuális környezetek erre a rétegre épülnek, s fontos elemük a Java virtuális gép.[..], a LiquidVM-t. Ez a Java virtuális gép operációs rendszer nélkül képes a hypervisoron futni, így a Java alkalmazások is közvetlenül a virtualizációs rétegen működnek. A BEA architektúra előnye, hogy teljesen elhagyja az operációs rendszert, ami a teljesítmény növekedését eredményezi.

    az elnevezéseken lehet vitatkozni, de alapvetően megvan minden ami kell. egy vmware esx server, amit ők hypervisor-rétegnek hívnak [sztem ezt nem egybe kell írni], és ez biztosítja azokat az oprendszer-funkciókat amit hiányolsz. ezen csücsül egy java vm (virtualizációra felkészítve) stb
    most hogy teljesen elhagyja az oprendszert stb az nyilván elégég marketingszagú és úgy kell érteni hogy a virtualizáció nem a hagyományos os-ek fölött történik, de nyilván aki akarja érti. ez maga az esx.

    [Szerkesztve]

  • bambano

    titán

    válasz Eperfa #7 üzenetére

    No, akkor vesézzünk:

    ''ha a virtualizációt hagyományos eszközökkel kívánjuk megoldani, a konszolidáció kevésbé hatékony'': mik azok a hagyományos eszközök? mit tekint ő kevésbé hatékonynak?

    ''Ebben az esetben ugyanis a teljes alkalmazásstacket, beleértve az operációs rendszert is, annyi példányban kell futtatnunk, ahány virtuális környezetet szeretnénk kialakítani.'': ez konkrétan nem igaz, mert lehet chrootolva vagy uml-ben is futtatni java vm-eket. figyelembe véve még azt a későbbi állítást, miszerint az oprendszerből keveset használ a jvm, ezért nem lehet azt mondani, hogy hajde nagyon sokat ront egy oprendszer a jvm teljesítményén.

    ''operációs rendszer szolgáltatásai közül csak nagyon keveset használ fel, ezért a hagyományos megoldás igen erőforrás-pazarló.'': ha keveset használ, akkor legfeljebb pár százK memóriát pazarol, az operációs rendszer (pontosítsunk: a rendszermag) azon részei nem foglalnak semmi erőforrást, amit nem használ a jvm. Mivel kevés ilyet használ, ezért kevés pazarlás történik (nem nulla a pazarlás, ezt elismerem).

    VMWare esx: ez állítólag operációs rendszer nélkül fut: mint itt már megjegyezték, az esx-ben nagyjából minden benne van, ami egy operációs rendszerhez kell, hiszen hogyan másképp futhatna. Nem fognak hardverfüggő cuccokat rakni magába a virtualizációba, kell egy kernel jellegű dolog. Még akkor is, ha a virtualizáció és a fizikai hw meghajtók, ütemező, memóriamenedzser, hálózati driverek, stb. stb. egy darab exe-ben (kernellé linkelhető objektumban, mindegy, minek hívjuk) vannak

    Az ok, hogy csináltak spéci vm-et, ami közvetlenül a hypervisoron fut, és itt esetleg kimaradt az oprendszer. Ennek hasznosságán lehetne vitatkozni, hiszen ha kihajítják pl. a linux kernelt (de itt akár windows kernelt is mondhatnék), akkor ezzel kihajítják azt a rengeteg optimalizálást, finomhangolást is, amit a linux és a windows fejlesztők 15-20 év alatt beleöltek a rendszermagokba és megírták ennek egy részét újra. Kétségeim vannak afelől, hogy egy jvm fejlesztő jobb block cache-t ír, mint akár az ms, akár a linuxosok.

    Tehát maradjunk annyiban, hogy indokok nélkül nevezheted fikázásnak a témát, de vannak indokok is, amik a leadott pr anyag szintjét bizonyítják. Összefoglalva a kifogásom lényegét: ha (a cikk szerint) állítólag olyan keveset használja az oprendszert a vm, akkor annak kimaradása szükségképpen csak keveset gyorsít. Amiben nem vagyok teljesen biztos, de ez utóbbi mondatod veheted flémnek.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • nyaralasptt

    csendes tag

    válasz bambano #8 üzenetére

    Az uml-lel megoldhato, hogy csak a specifikus resz memoriastack-jet lemendsd es egy masik gepen /akar masik hw kornyezet pl.: mainframe -> x-86 vagy egy gep -> tobb server stb./ tovabb futtasd ugy, hogy az alkalmazas ebbol nem vesz eszre semmit?

    Amikor olvastam a cikket nekem is az ugrott be, hogy sebessegben valoszinuleg nem sokat szamit /mondjuk lassabb valoszinuleg nem lesz, de tipikus javas kornyezetben nem a javas server szokott a szuk keresztmetszet lenni, hanem az adatbazis(ok)/. Az hw eroforrasok kihasznaltsaga viszont kellemesen alakulhat a dinamikus eroforrashozzarendeles miatt, aminek a tamogatasat ez a technika segitheti.

    Java vilagban az optimalizaciot tipikusan a jol atlathato strukturak es a JIT jellemzi, szoval en nem latom gondnak, hogy kidobjak a francba az alacsony szintu, es tulajdonkeppen felesleges retegeket az azokban implementalt optimalizaciokkal egyutt. A targyalt felepitest is azert latom frankonak, mert sikerul megszabadulni egy csomo olyan dologtol ,ami nem tartozik kozvetlenul /vagy sehogy/ a lenyeges funkcionalitashoz.

    GITS

  • Eperfa

    tag

    válasz bambano #8 üzenetére

    (azt nem értem mondjuk hogy miért bassza fel mindenki az agyát ha a sajátjától eltérő véleményt hall de nem baj)

    mielőtt idézgetek, leszögezem a következő, számomra vitathatatlan igazságokat:
    a.) sok példányban futtatni egy OSt csak azért h sok java vmed legyen felesleges és erőforráspazarló
    b.) nem a bea kezdte két hét alatt újraírni a világot, nem véletlen használják az esxet
    c.) a vmware esx az egyik igen elterjedt, nagyvállalati környezetben is sokat használt, jó minőségű virtualizációs megoldás. ebből két dolog következik: az egyik, hogy ők sem két hete kezdtek gondolkozni a saját kerneljük felépítésén, a másik pedig hogy jobb támogatást nyújt a virtualizációhoz mint a 'hagyományos' oprendszerek (ez egy meglepő állítás annak fényében h erre lett kitalálva..)
    d.) ez természetesen egy pr cikk marad, aminek az a lényege h az üzleti vezető is megértse meg neked és nekem is legyen fogalmam arról h mi is ez. nem arról vitatkozok h ez tökéletes lenne, főlegnem szakmai szempotból, csak annyit mondtam h a csuklóból odavágott szarozás (amikor nem is értetted hogy hogy működik) kicsit gyorsvolt sztem.

    'ha a virtualizációt hagyományos eszközökkel kívánjuk megoldani, a konszolidáció kevésbé hatékony'': mik azok a hagyományos eszközök? mit tekint ő kevésbé hatékonynak?

    a hagyományos eszköz nála feltételezhetően az egy oprendszeren belül futtatok több másiakt, mindegyiken egy vm. ez képest nyilván kevésbé hatékony mint az övék, de ugye ide tartozik a következő idézet is (vagyis hogy tényleg ez-e a legjobb 'hagyományos' megoldás)

    ''Ebben az esetben ugyanis a teljes alkalmazásstacket, beleértve az operációs rendszert is, annyi példányban kell futtatnunk, ahány virtuális környezetet szeretnénk kialakítani.'': ez konkrétan nem igaz, mert lehet chrootolva vagy uml-ben is futtatni java vm-eket.

    mélyen technikailag nem tudok vitatkozni a dologgal, de (javíts ki ha tévedek) feltételezem h a fentiek közül egyik sem nyújt pl olyan minőségű szeparációt, erőforráskontrollt, userkontrollt, mozgathatóságot és redundanciát mint amilyet egy esx alapú megoldással el lehet érni (a szavak szépek de tényleg gondold végig h pl egy chrootos megoldásnál hogy is néz ki pl az erőforráskontroll. a nice level azért nem egyenlő azzal amit egy esxben be lehet állítani.. meg ugye tényleg az hogy akármikor átteszem másik gépre, megszakítás nélkül fut stb) (ezen felül pedig kicsit házi hekkelés szagot érzek ami nagy cégeknél nem dívik, márpedig a célközönség nem én vagyok, de mondom, javíts ha nem így van. arról nem is beszélve h ha már amúgyis van esx alapú cucca a cégnek akkor valszeg még könnyebb az átállás)

    figyelembe véve még azt a későbbi állítást, miszerint az oprendszerből keveset használ a jvm, ezért nem lehet azt mondani, hogy hajde nagyon sokat ront egy oprendszer a jvm teljesítményén.

    sztem ez egy alapvető félreértelmezés. a jvm keveset használ az oprendszerből, azaz ottvan egy egész nagy oprendszer ami a bedugott usbs eszközök kezelésétől a hangkártyadriveren keresztül az automatikus updateig minden szart futtat, pedig mi csak egy szaros java vmet használunk rajta, amihez semmi szükség a fentiekre. éppen ezért ebből a 'hagyományos' oprendszerből futtatni 20 példányt a 20 vmhez sztem valóban pazarló (persze újra előjön a fenti kérdés h ez tényleg szükséges-e, nicns-e jobb megoldás)

    ''operációs rendszer szolgáltatásai közül csak nagyon keveset használ fel, ezért a hagyományos megoldás igen erőforrás-pazarló.'': ha keveset használ, akkor legfeljebb pár százK memóriát pazarol, az operációs rendszer (pontosítsunk: a rendszermag) azon részei nem foglalnak semmi erőforrást, amit nem használ a jvm. Mivel kevés ilyet használ, ezért kevés pazarlás történik (nem nulla a pazarlás, ezt elismerem).

    te is tudod h a dolog nem ilyen egyszerű, az a pár száz K nem pár száz K (főleg ha nem egy kiherélt linuxkernelről beszélünk hanem egy winről, persze jogosan merül fel a kérdés h annak van-e értelme, de lehet h vhol van), a prociterhelés nem 0, alá kell még egy teljes hwemuláció is, továbbá az összes oprendszert karban kell tartani, updateelni kell stb.

    Az ok, hogy csináltak spéci vm-et, ami közvetlenül a hypervisoron fut, és itt esetleg kimaradt az oprendszer. Ennek hasznosságán lehetne vitatkozni, hiszen ha kihajítják pl. a linux kernelt (de itt akár windows kernelt is mondhatnék), akkor ezzel kihajítják azt a rengeteg optimalizálást, finomhangolást is, amit a linux és a windows fejlesztők 15-20 év alatt beleöltek a rendszermagokba és megírták ennek egy részét újra. Kétségeim vannak afelől, hogy egy jvm fejlesztő jobb block cache-t ír, mint akár az ms, akár a linuxosok.

    pont ez a lényeg, ők nem foglalkoznak a hypervisor réteggel (amit hasonlíani lehet az ms/linux/... rendszerekhez), azt meghagyják a vmware-es srácoknak, akik pedig ebben azért nem rosszak..
    ők csak az esxen futó java vmtől kezdtek fejleszteni (és azt sem a 0ról)

    Tehát maradjunk annyiban, hogy indokok nélkül nevezheted fikázásnak a témát, de vannak indokok is, amik a leadott pr anyag szintjét bizonyítják. [...] Amiben nem vagyok teljesen biztos, de ez utóbbi mondatod veheted flémnek.

    az ilyenek nem tudom minek kellenek de biztos.

    sztem oda ahova ezt tervezték oda ötletes és jó a cucc. magánvélemény.

    (kíváncsi vagyok h közelednek-e majd az álláspontok de sajnos megyek el este uh válaszolni nem fogok tudni egy jó hétig)



    [Szerkesztve]

Új hozzászólás Aktív témák