JavaRE na linuxu: tuning

[Petrik]

V praci resim nasledujici problem.
Zadani:
mame cca 40 PC, vetsina na linuxu (postupne se na nej migruje z XP) a na vsech bezi jedna java aplikace, ktera prochazi web a neco z nej stahuje. Cim vice instanci teto aplikace pobezi, tim lepe. Problem je, ze tato java aplikace je dost pametove i procesorove narocna, prumerna spotreba RAM jedne instance je cca 500MB, ale protoze nejaka pouzita knihovna ma problem s uvolnovanim pameti, obcas se stane (cca kazda desata) ze sezere veskerou pamet, kterou ma k dispozici. Pamet tedy omezujeme parametrem -Xmx a navic po pevne dane dobe aplikace skonci a spusti se znovu.
Me reseni:
Prvni, co jsem udelal, byl upgrade RAM na vsech strojich na 8GB (vice neumi) a instalace 64-bit OpenSuSE, vysledek vsak nebyl uspokojivy. XP s 3GB RAM dokazi bezet s 5 instacema, takto jsem se dostal na pouhych 9-10. Dalsim krokem byla instalace 32-bit JRE, vyledkem cehoz je, ze dokazu spustit 16 instanci zaroven, vyuziti swapu se prumerne pohybuje na cca 2-3GB a load je na cca 2-4, tedy je stale pouzitelny. Mimochodem nejen ze 32-bit JRE zere az o 60% mene RAM, ale zaroven ma byt i o ccaa 10-20% rychlejsi nez 64bit. Samozrejme jsem povypinal sluzby co to slo, nebezi tam ani Xka. Ma otazka zni: napada nekoho, co bych jeste mohl udelat pro maximalizaci poctu instanci one java aplikace? Samozrejme budeme hledat optimalni velikost -Xmx parametru, dulezite ale je abychom moc casto neskoncili s haskou OutOfMemory. Diky za jakekoli postrehy.

[Gargamel]

Docela silena aplikace, mit moznost, radeji bych ji prepsal Nevim jestli v Jave existuje neco jako Valgrind pro ELF binarky, zkus se podivat.

Ke tvym zjistenim: ano, u 64-bit mas dvojnasobnou velikost pointeru a jine zarovnavani instrukci, mnozstvi "ztracene" pameti se ale lisi aplikace od aplikace, prumerne 10-15%. U 32-bit userspace aplikace s 64-bit kernelspace jsi omezeny adresovatelnymi 4GB na proces... Pokud se nepletu, Java VM se sdili, tudiz se nikdy nedostanes pres 4GB u 32-bit JRE. Ale nezda se mi to.

Omezeni systemovych prostedku se da taky resit pres ulimit, coz ti ale v pripade sdilene VM nepomuze.

Nejsem Javista, nicmene muzes vyzkouset jine JVM - stary Blackdown (konci na 1.4.2), nove OpenJDK/IcedTea (6 a nejaky draft 7), IBM ma asi taky nejakou svou VM a pak teoreticky GCJ/ECJ? (jestli to nejsou jen prekladace bez runtime VM). Kazda VM je jinak optimalizovana a mohla by pomoct vyresit tve problemy. V ruznych distribucich se prepinani system/user Java VM resi jinak, v Gentoo je na toto eselect. Chce to trochu experimentovat.

Dalsi hint: castejsi volani garbage collectoru behem behu asi nepomuze, co?

Poslednim resenim, nad kterym muzes uvazovat, je virtualizace, prip. clusterovani pro maximalni vyuziti dostupnych prostredku.

[Petrik]

Docela silena aplikace, mit moznost, radeji bych ji prepsal Nevim jestli v Jave existuje neco jako Valgrind pro ELF binarky, zkus se podivat.

vubec netusim, nejsem koder, forwardnu to vyvojarum kazdipadne ona ta aplikace toho dela docela dost a pry neni moc moznost ji nejakdramaticky zkrouhnout, ledaze vyjde nova verze nejake te knihovny, kteoru to pouziva a ktera pry docela sux.

Ke tvym zjistenim: ano, u 64-bit mas dvojnasobnou velikost pointeru a jine zarovnavani instrukci, mnozstvi "ztracene" pameti se ale lisi aplikace od aplikace, prumerne 10-15%. U 32-bit userspace aplikace s 64-bit kernelspace jsi omezeny adresovatelnymi 4GB na proces... Pokud se nepletu, Java VM se sdili, tudiz se nikdy nedostanes pres 4GB u 32-bit JRE. Ale nezda se mi to.

Tak toto nepozoruji, s 32bit JRE (100% 32bit podle jmena rpm i podle java -version) neni problem spotrebovat 8GB RAM + 4GB SWAP a sestrelit stroj tak dokonale, ze ani OOM killer nepomuze, protoze mame infinite loop co to spusti okamzite znovu...to se mi stalo uz 3x. Kazdopadne se SUN JRE 1.6.u15 je rozdil ve spotrebe pameti 32 vs. 64 fakt velky, minimalne 40-50%, coz ale vysi i nekde na nejakych fundovanych strankach... jinak jave jako takove muzes dat ve 32bit JRE jen 2GB RAM, vic jde pouze na sparcu ci co.

Nejsem Javista, nicmene muzes vyzkouset jine JVM - stary Blackdown (konci na 1.4.2), nove OpenJDK/IcedTea (6 a nejaky draft 7), IBM ma asi taky nejakou svou VM a pak teoreticky GCJ/ECJ? (jestli to nejsou jen prekladace bez runtime VM). Kazda VM je jinak optimalizovana a mohla by pomoct vyresit tve problemy. V ruznych distribucich se prepinani system/user Java VM resi jinak, v Gentoo je na toto eselect. Chce to trochu experimentovat.

Ja se obavam ze toto bude problem, protoze ta aplikace je asi dost nekompatibilni s neSUN JRE, pry to zkoseli a vubec to nejelo. Ale muzem to testnout znovu.

Dalsi hint: castejsi volani garbage collectoru behem behu asi nepomuze, co?

Rovnez netusim, ale obavam se ani toto uplne nepomuze, protoze jak jsem vypozoroval tak kazdy cca 6. proces dostane nejaky memory leak (nastesti to neni nakazlive) a sezere veskerou jemu povolenou pamet. Problem ze kdyz mu pamet omezim vice nez soucasnych 768MB, tak casteji skonci s OutOfMemory

Poslednim resenim, nad kterym muzes uvazovat, je virtualizace, prip. clusterovani pro maximalni vyuziti dostupnych prostredku.

Nad tim jsem hodne premyslel, spis nez o virtualizaci o nejakem clusteru, jenomze za soucasneho stavu kazdy stroj pouziva prumerne 2GB SWAPu a i tak to docela funguje, kdyz se sejde vice vyteklych procesu (memory leak), tak je tam chvili i 4GB a load cca 15-20 a obavam se ze toto by cluster ci vritualizace uplne nepobrala, resp. bych nemohl provozovat tolik procesu, protoze tam je vzdy nejaky overhead a nejaka rezie navic. Nevim to jiste, ale nejak si neumim predstavit, jak by napr. takovy OpenMOSIX (uz mrtvy projekt mimochodem) pouzival lokalni swap. Jeste se na ty clustery kouknu, bylo by to uzasne zjednoduseni spravy, ale obavam se ze za cenu o dost nizsiho vykonu. Kazdopadne diky moc za postrehy, predam to vyvojarum a zkusim jeste nejak otestovat ty dalsi JRE.

Mimochodem, jen pro pobaveni, kdyz jsem na win XP 64-bit + 32bit JRE pustil stejne mnozstvi procesu jako na linuxu, tedy 16, tak ani skoro neslo hybat mysi linuxova konzole je uplne vpohode.

Dneska se ale stala divna vec. Na jednom ze stroju bezi RMI server, do ktere downloaderi ukladaji stazena data a on je pak serviruje prekladacum. Tento server bezi bez resetu a protoze potrebuje vice RAM (5GB), je tam 64-bit JRE. Zaroven tam bezi dva prekladace (kazdy 1GB RAM). Prijdu ke stroji co bezel cca 4 dny a najednou koukam, ze disk porad sviti a server nejede. Po chvili laborovani koukam ze vyuzito je 2GB SWAPu, prestoze soucet procesu v top daval cca 90% RAM. Killnul jsem tedy oba prekladace, takze na tom 8GB stroji zustal jen server (5GB), ale stroj porad swapoval, zajimave bylo ze load byl jen cca 1.5. Po chvili marneho snazeni jsem vypnul swap, coz trvalo cca 5min a pak se RMI server zase uplne normlane rozjel. Nechapu, co to jako melo byt, ale SWAP na tomto stroji proste nebude a fidli. Nastesti neni portreba.