NOVINKA - Online rekvalifikační kurz Python programátor. Oblíbená a studenty ověřená rekvalifikace - nyní i online.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Diskuze: Java heap size

V předchozím kvízu, Online test znalostí Java, jsme si ověřili nabyté zkušenosti z kurzu.

Aktivity
Avatar
martinsakra
Tvůrce
Avatar
martinsakra:26.3.2014 21:15

zdravim mám zajímavý problém, mám aplikaci která je sama o sobe docela náročná na pamět a výpočetní kapacitu, proto jsem na ni průbežně dělal různé optimalizace a zjištuji, že jsem se dostal to velmi zvláštního stavu
Pokud spouštím muj program tak zabírá různě mnoho paměti, a to v rozmezí cca 90-150Mb nebo v rozmezí 450-650mb když se "nedaří", tento rozptyl je bez jakékoliv změny kodu.
Debug v netbeans mi ale pravidelně ukazuje hodnoty mnohem nižší (resp ty v rozmezí 90-150) i když task manager

Pokus se podíváte na obrízek tak vydíte že mi to vystřelilo do slušné velikosti a pak to padlo (ale zabraná pamět se nepustila), ale někdy se to nestává. myslíte že za to muže jen GC nebo je někde memory leak?

Odpovědět
26.3.2014 21:15
Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote.
Avatar
Silvinios
Tvůrce
Avatar
Odpovídá na martinsakra
Silvinios:28.3.2014 7:48

Mohl bys alespoň nastínit, co program dělá, resp. co se děje "uvnitř". Ačkoliv se kód nemění, mohou se měnit vstupy.

GC opravdu nemusí uvolnit všechnu paměť, pokud má k dispozici dostatek volné paměti. Nejspolehlivější se mi zdá nastavit max heap na nějakou rozumnou mez a nechat program běžet dostatečně dlouho a opakovat výpočet stále dokola. Pokud se velikost heap dlouhodobě zvyšuje, až nakonec dojde k OutOfMemoryError, na vině je memory leak.

K sledování využití paměti se mi osvědčilo používat VisualVM, které je součástí JDK od Oracle.

 
Nahoru Odpovědět
28.3.2014 7:48
Avatar
Luboš Běhounek Satik
Tvůrce
Avatar
Odpovídá na martinsakra
Luboš Běhounek Satik:28.3.2014 23:07

Defaultně se v Javě tuším paměť začne uvolňovat, až když je zabráno méně než 10% alokované paměti, ale dá se to někde změnit.

Co ti na začátku zabere tolik paměti takhle na dálku asi nezjistíme, můžeš zkusit si na vytipovaná místa hodit breakpointy a sledovat obsazenou paměť, abys zjistil, kde to asi nastane...

Nahoru Odpovědět
28.3.2014 23:07
https://www.facebook.com/peasantsandcastles/
Avatar
coells
Tvůrce
Avatar
coells:28.3.2014 23:22

Hodně složitá záležitost a je lepší na to nesahat.

Když se zvýší tzv. memory pressure, může se heap uvolňovat daleko častěji, ale ani trochu to neprospívá garbage collectoru a výkonnosti. Z toho důvodu mají skoro všechny VM, kde běží GC, hodně agresivní přístup k paměti. Chovají se jako peklo - co jednou schvátí, to už nenavrátí.

Pokud je s pamětí problém, pak se dá udělat detailní profiling paměti v JVM, na to existují hezké nástroje. Pokud ale program zabírá "různě" paměti, pak to může být způsobené tím, že GC nestíhá. Ve chvíli, kdy aplikační pamět bobtná, dochází v OS k přesouvání virtuální paměti a swapování, v závislosti na vytíženosti HW pak může nebo nemusí být GC naplánován vždy stejně.

Tohle je prostě daň za to, že se nemusíš starat o uvolňování paměti. Ve chvíli, kdy je to velký problém, se klíčové části přepisují do C++ a z Javy se volají externí knihovny. Ale dokonce i v C++ může dojít k podobným problémům, jestliže na stroji běží další aplikace, které zvyšují memory pressure na úrovni OS.

 
Nahoru Odpovědět
28.3.2014 23:22
Avatar
martinsakra
Tvůrce
Avatar
Odpovídá na martinsakra
martinsakra:28.3.2014 23:43

No na vysvětlení co to děla atd. Mám cca 4000 obejtků + další věci, který mě zabárají odhadem 80 MB, co beru jako docela použitelné číslo (kolik z toho těch 4000 obejtků netušim odadl bych tak pulka), problém je že každou iteraci vytvořím cca 4000 nových objektů, z nichž většina nepřežije více než jednu dvě iterace (simulace souboju o limitovane zdroje), proto mi bystřelí vždycky cca na dvojnásobek pamět, heapp si naalokuje navíc + ještě rezervu a jsem na číslech co vidítě

Zátěžový tes v netbeanech v debug mode, měl jsem asi 18 000 onjektů naalokováno 400MB reálně používáno asi 200mb po zavolácí gc (přes netbeans) mi to padlo na nějakých 120MB

Ocenil bych nějaký efektnivní dispose :D nebo vrácení heapu

Nahoru Odpovědět
28.3.2014 23:43
Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote.
Avatar
martinsakra
Tvůrce
Avatar
Odpovídá na coells
martinsakra:28.3.2014 23:45

no výkonostně neprospívá, jsem schopen odhadnout dobu kdy algorytmus nic nedělá (čeká na další vstup) a v tu chvíli klidne muže pamět uvolnit a to že si ji pak znovu alokuje mi nevadí, a po výkonnostní stránce nějaká alokace paměti je zanedbatelná

Nahoru Odpovědět
28.3.2014 23:45
Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote.
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 6 zpráv z 6.