abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 01:22 | Nová verze

    Byla vydána verze 1.91.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

    Ladislav Hagara | Komentářů: 0
    dnes 00:11 | IT novinky

    Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.

    Ladislav Hagara | Komentářů: 0
    včera 23:44 | Komunita

    Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.

    Ladislav Hagara | Komentářů: 0
    včera 15:22 | Nová verze

    Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.

    Ladislav Hagara | Komentářů: 1
    včera 12:55 | Nová verze

    Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).

    Ladislav Hagara | Komentářů: 2
    včera 02:55 | Nová verze

    Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.

    Ladislav Hagara | Komentářů: 0
    včera 01:22 | IT novinky Ladislav Hagara | Komentářů: 0
    29.10. 17:00 | Upozornění

    Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].

    Ladislav Hagara | Komentářů: 9
    29.10. 16:44 | IT novinky

    Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.

    Ladislav Hagara | Komentářů: 6
    29.10. 14:11 | Komunita

    Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).

    Ladislav Hagara | Komentářů: 2
    Jaké řešení používáte k vývoji / práci?
     (36%)
     (48%)
     (19%)
     (19%)
     (22%)
     (17%)
     (21%)
     (17%)
     (18%)
    Celkem 290 hlasů
     Komentářů: 14, poslední 14.10. 09:04
    Rozcestník

    Dotaz: Java - garbage collector

    25.8.2009 13:06 merlik | skóre: 13 | blog: merlik
    Java - garbage collector
    Přečteno: 568×

    OS: 2.6.18-128.1.10.el5PAE i686 Linux
    Java: 1.6.0_16
    Tomcat: 6.0.18 (s parametry: -XX:MaxPermSize=512m -Xms512m -Xmx512m -server)
    PostgreSQL: 8.1.11-1.el5_1.1

    Představte si situaci, kdy v Tomcatu je nasazena aplikace (obyč webová aplikace se Springem, Hibernatem, JSF, komponentami od Infragistics (přesné verze mohu asi dohledat)) připojující se do Postgresu. Tohle si jen tak žije, nikdo na to nešahá a stejně tam dle visualvm vznikají periodicky nějaké objekty. Po chvíli je většina z nich odklizena garbage collectorem (=v grafu využití heapu vznikne tzv. pila naznačující nějaký leak). A takhle se to stále opakuje, ale postupně (pomalu) vzrůstá využití heapu. Jestli jsem dobře koukal, tak tam postupně vznikají integery. Nakonec to (po pár dnech) skončí na nedostatku paměti (heap má 512MB).

    Problému se dá předejít vynucením GC z připojeného visualvm. Ten pak uklidí heap na stav po spuštění aplikace.

    A nyní bych měl dvě otázky. Jak zjistit, kdo je "autorem" problematických objektů? Dá se to? Nejsem java guru a tohle mám před sebou jako černou skříňku, která zlobí :)

    A případně, dá se nějakými konfiguračními volbami donutit GC k tomu, aby se čas od času spustil v módu jako se provede z visulavm a uklidil všechno, co uklidit může? Prozatím mi uniká, že samovolně tohle nedokáže a tomcat nakonec skončí jako nepoužitelný, i když to uklidit lze.

    Předem děkuji za jakékoliv podněty, třebas jen ke studiu, pač googlu jsem zatím nedokázal položit správný dotaz.

    I cesta může být cíl.

    Odpovědi

    25.8.2009 13:29 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Java - garbage collector
    Pár základních tipů bych měl:
    1. Nechte GC vypisovat, co dělá (-XX:+PrintGCDetails, -XX:+PrintGCTimeStamps, pro hrubší sledování jinfo -gcutil).
    2. Při OutOfMemory si nechte dumpnout heap (-XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=/home/ladicek/work/dumps). Případně si ho dumpněte ručně, VisualVM by to mohl umět, případně jmap.
    3. Eclipse Memory Analyzer je váš přítel.
    4. Pokud jde o permgen, zvyšte jeho maximální velikost (-XX:MaxPermSize=128M) a modlete se.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    25.8.2009 13:41 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Java - garbage collector
    Ako konkretne vyzera message OOME, na ktoru JVM nakoniec spadne? Stale su dve moznosti, a to ze pamat dosla na heape, alebo v 'permgen'; vzhladom na vyssie uvedene nastavenie maxpermsize predpokladam, ze tuning tejto oblasti uz bol v minulosti potrebny.

    Ak manualne spusteny full gc veci uprace, ale backgroundovo spusteny skonci na OOME, problem by nemusel byt v tom, ze nejake veci su "negarbagecollectovatelne", ale v tom, ze gc trva prilis dlho; JVM totiz vyhodi OOME aj vtedy, ak sa za stanoveny cas nepodari uvolnit urcite mnozstvo pamate, ale toto nastava iba pri plnom heape. Odporucam skusit inkrementalny GC (-Xincgc) alebo vzhladom na pouzitu javu aj G1GC (-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC). Same o sebe toto vyzera dost podozrivo: cokolvek dokaze urobit explicitne spusteny GC, dokaze urobit aj backgroundovy GC (ono je to ten isty, ze ano) v podmienkach plneho heapu. Naplnenie heapu odpali full-gc tak isto ako jeho explicitne volanie. Zda sa mi zvlastne, ze to prve je neuspesne, zatial co to druhe funguje.

    Pricinou, preco niektore objekty nie su collectovane, i ked by potencialne mohli byt, je neukoncena finalizacia. Kazdopadne by bolo vhodne najskor urobit thread dump v momente padu a analyzovat, ake objekty zaberaju vela miesta.

    Uzatvaraju sa databazove spojenia? Pouziva sa connection pooling zabezpecovany webovym kontajnerom? Nesnazi sa aplikacia robit si ho sama? Su pady nahodne, alebo k nim dochadza pri nejakej specifickej akcii (zalohovanie, export/import udajov, vacsi pocet pouzivatelov)?

    Len pre istotu: ta Java nie je nahodou OpenJDK?
    25.8.2009 14:05 merlik | skóre: 13 | blog: merlik
    Rozbalit Rozbalit vše Re: Java - garbage collector

    Používám javu od SUNu, žádný klon.

    Co se týká provedení dumpu v momentě, kdy "dojde paměť", tak visualvm provede nejdřív ten svůj GC a vyčistí paměť, takže se nic nedozvíme. Ale kamarád už našel ještě jiný způsob, ale o tom ještě tolik nevím.

    Co se týká db, dělá je tomcat a s tím snad problém není.

    Pády jsou náhodné, prostě i bez využívání aplikace a serveru prostě po nějaké chvíli paměť dojde. Přesnou vyjímku dodám, jen co ji najdu :)

    Co se týká toho, že gc hlásí out-of-memory, když nestíhá, tak to vím. Ale ten stroj nic jiného nedělá, load tam není žádný, ale prostě jsou tam "negarbagecollectovatelné" objekty, které se snažím nějak identifikovat. Děkuji za tip s finalizací. Zkusím využít všechny návrhy a něco zjistit.

    I cesta může být cíl.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.