Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. Virtuális környezet Java alkalmazásokhoz
Keresés

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

  • #10 Eperfa tag bambano #8
    Új Válasz #10
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    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]

  • #9 nyaralasptt csendes tag bambano #8
    Új Válasz #9
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    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.

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