Java jako linuxová služba

[KapitánRUM]

Ahoj,

změnilo se něco v možnosti spustit Javový kód jako démona na Linuxu nebo to jde pořád stejně blbě a "Nazdar vole" sedící v paměti sežere ~50MB operačky?

Díky.

[Reklama]

[Vladimír Drgoňa]

Mne zožerie cron napísaný v Jave aj 200MB. Je to dosť veľká aplikácia, ktorá spracováva väčšie množstvo údajov, takže to chápem. Pri 16GB RAM v tom nevidím problém a na notebooku to nepúšťam.

[eMko]

Žádná změna, jde to stejně blbě jako minulý týden, úplně dlabou na vývoj, Java ustala na mrtvém bodě ... :-)

Teď vážně: za poslední roky se AFAIK nic moc nezměnilo. Osobně nevidím moc důvod psát démona v Javě.

"Hello world" (Swing) mi bral na linuxu operační paměti kolem 20-25MB, což nebylo o moc jiné než Python+Qt nebo Mono+Win.Forms. Na Windows to bude podobné. Na druhou stranu Hello World program sám o sobě není nijak vypovídající.

Pokud chceš něco slušného, multiplatformního, jednoduchého, v čem Hello World nezabírá moc paměti, tak se podívej třeba na Ultimate++ http://ultimatepp.org/ .

[Ivan]

změnilo se něco v možnosti spustit Javový kód jako démona na Linuxu nebo to jde pořád stejně blbě a "Nazdar vole" sedící v paměti sežere ~50MB operačky?

Nevim jestli to neni jen pokus o flame, ale presto odpovim. JVM je virtualni masina, ktera si sama pro sebe uzurpuje nektere vlastnosti kernelu. Jako treba memory management. Ciste teoreticky by nikdy nemela sezrat vic pameti nez ji urcis pomoci parametru -Xmx(heap size).

Pokud spoustis aplikaci v Jave, tak musis dopredu udekat sizing a musis rozhodnout kolik pameti (maximalne) muze aplikace pouzit.
Kdyz se nad tim zamyslis, tak to neni zase uplne spatna vlastnost. Treba database jako Informix, Oracle anebo i Posgress funguji podobne.

[KapitánRUM]

Díky, přesně tohle jsem měl na mysli.

[Reklama]

[eMko]

Ciste teoreticky by nikdy nemela sezrat vic pameti nez ji urcis pomoci parametru -Xmx(heap size).

Jenom doplním info - vždycky "sežere" trochu víc - tohle je jen omezení velikosti haldy. Kromě haldy potřebuješ ještě nějaký jiný věci (např. zásobník přes který se předávají parametry funkce - JVM je klasická zásobníková mašina (tím "klasická" myslím to samé co i386, ne AK-47) ... ), ale ten "overhead" není moc velký)

[Pavel Tisnovsky]

Žádná změna, jde to stejně blbě jako minulý týden, úplně dlabou na vývoj, Java ustala na mrtvém bodě ... :-)

Teď vážně: za poslední roky se AFAIK nic moc nezměnilo. Osobně nevidím moc důvod psát démona v Javě.

"Hello world" (Swing) mi bral na linuxu operační paměti kolem 20-25MB, což nebylo o moc jiné než Python+Qt nebo Mono+Win.Forms. Na Windows to bude podobné. Na druhou stranu Hello World program sám o sobě není nijak vypovídající.

Pokud chceš něco slušného, multiplatformního, jednoduchého, v čem Hello World nezabírá moc paměti, tak se podívej třeba na Ultimate++ http://ultimatepp.org/ .

Nojo, projekt Jigsaw, ktery toto mel docela elegantne resit, byl zase odsunuty, takze si netroufam predikovat, kdy v JDK bude (devitka?). V kazdem pripade, pokud by ten demon nemel byt nejak narocny na vypocetni vykon, tak se da s pameti hrat, viz zminene -Xmx, potom -Xms, dale -Xss pro stack size (ale ten je maly, nejakych 1/2 mega) a hlavne compressed oops na 64bitovych masinach - to muze dost pomoci napriklad tehdy, pokud projekt pouziva kosatou strukturu objektu s mnozstvim referenci.

A ja bych se nebal jit jeste dal - namisto Hotspotu zkusit nahodit JamVM, zkuste uvidite (neda se rict obecne, KDY je JamVM lepsi reseni, ale na nejakej bazmek, co sem tam neco prijme pres socket to je lepsi nez mlaticka typu HotSpot).

[Tomas]

Ciste teoreticky by nikdy nemela sezrat vic pameti nez ji urcis pomoci parametru -Xmx(heap size).

Jenom doplním info - vždycky "sežere" trochu víc - tohle je jen omezení velikosti haldy. Kromě haldy potřebuješ ještě nějaký jiný věci (např. zásobník přes který se předávají parametry funkce - JVM je klasická zásobníková mašina (tím "klasická" myslím to samé co i386, ne AK-47) ... ), ale ten "overhead" není moc velký)

Jen doplnim ze krom tohoto "maleho" overhead-u vetsina respondentu zapomina, že PermGen se nepocita do HeapSize(Xmx Xms).
PermGen se pouziva laicky řečeno "na prototypy a tridy"(ne objekty samotne).

Ještě doplním, že taky může být rozdíl na/v čem spouštíte a co za aplikaci.
Situace, kdy jdk oracle aplikace s heap <1,2G + =<1/4 overhead ci mene a proste tohle neprekroci. (enterprise SW)
Situace, kdy na openjdk heap 300M + =<5/4 overhead.

[KapitánRUM]

Díky, přesně tohle jsem měl na mysli.

Tak tohle jsem fakt nepsal 
Přesto díky.

[Ivan]

Nojo, projekt Jigsaw, ktery toto mel docela elegantne resit, byl zase odsunuty, takze si netroufam predikovat, kdy v JDK bude (devitka?). V kazdem pripade, pokud by ten demon nemel byt nejak narocny na vypocetni vykon, tak se da s pameti hrat, viz zminene -Xmx, potom -Xms, dale -Xss pro stack size (ale ten je maly, nejakych 1/2 mega) a hlavne compressed oops na 64bitovych masinach - to muze dost pomoci napriklad tehdy, pokud projekt pouziva kosatou strukturu objektu s mnozstvim referenci.

Co presne ten Jigsaw dela? Umi to menit Xm* parametry za behu? Tohle je vec ktera me trapi. Mame HW ktery podporuje hotplug RAM a hoplug CPU. Dokonce i OS to podporuje, ale stejne je to vsechno na prd, kdyz musime nakonec restartovat aplikaci.

[Pavel Tisnovsky]

Nojo, projekt Jigsaw, ktery toto mel docela elegantne resit, byl zase odsunuty, takze si netroufam predikovat, kdy v JDK bude (devitka?). V kazdem pripade, pokud by ten demon nemel byt nejak narocny na vypocetni vykon, tak se da s pameti hrat, viz zminene -Xmx, potom -Xms, dale -Xss pro stack size (ale ten je maly, nejakych 1/2 mega) a hlavne compressed oops na 64bitovych masinach - to muze dost pomoci napriklad tehdy, pokud projekt pouziva kosatou strukturu objektu s mnozstvim referenci.

Co presne ten Jigsaw dela? Umi to menit Xm* parametry za behu? Tohle je vec ktera me trapi. Mame HW ktery podporuje hotplug RAM a hoplug CPU. Dokonce i OS to podporuje, ale stejne je to vsechno na prd, kdyz musime nakonec restartovat aplikaci.

No v ramci projektu Jigsaw se mel mj. vyresit jeden dost velky a leta se tahnouci problem - modularita samotneho JRE (a JVM). V soucasnosti je JRE vlastne monoliticka vec, kde - zjednoduse receno - vsechno zavisi na vsem, takze napriklad pro nejakou aplikaci typu "Hello world" se pouziva JRE/JVM s moznosti prace s GUI (ATW/Swing), filesystemem, siti, security knihovnama, zvukem atd. atd.

Myslenkou bylo udelat v JRE poradek a nasledne tak zajistit moznost modularizace, kdy by se v ramci deskriptoru aplikace reklo, co ta aplikace vyzaduje. Pro GUI aplikaci by se tedy natahly i GUI knihovny, pro Applet by se NEtahaly veci okolo filesystemu a print systemu, jednoduchy daemon ci "Hello world" by si natahl jen java.io a nejaka jednoducha webovka by si taky vystacila jen s java.net a java.io - ted to hodne zjednodusuju, ale zaklad te myslenky je asi jasny.

Ad -Xm* - hmm mozna, ale skutecne jen mozna by to slo pres JXM, ale u nekterych parametru si myslim, ze bude umozneno jen cteni.