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 12:33 | Nová verze

Byla vydána nová stabilní verze 1.8 (1.8.770.50) webového prohlížeče Vivaldi (Wikipedie). Z novinek vývojáři zdůrazňují vylepšenou historii prohlížení. Ukázka na YouTube. Chromium bylo aktualizováno na verzi 57.0.2987.111.

Ladislav Hagara | Komentářů: 0
dnes 05:55 | Zajímavý projekt

Google na svém blogu věnovaném open source představil portál Google Open Source informující mimo jiné o více než 2000 open source projektech vyvíjených nebo používaných v Googlu.

Ladislav Hagara | Komentářů: 0
dnes 03:33 | IT novinky

Pro společnost Red Hat skončil 28. února fiskální rok 2017. Dle finančních výsledků bylo čtvrté čtvrtletí, stejně jako celý fiskální rok 2017, opět úspěšné. Tržby jsou zvyšovány již 60 čtvrtletí v řadě. Za čtvrté čtvrtletí 2017 to bylo 629 milionů dolarů, tj. meziroční nárůst 16 %. Tržby za celý fiskální rok činily 2,4 miliardy dolarů, tj. meziroční nárůst 18 %.

Ladislav Hagara | Komentářů: 2
včera 18:22 | Bezpečnostní upozornění

V balíčku eject, příkaz pro vysunutí CD/DVD z mechaniky, v linuxových distribucích Ubuntu (USN-3246-1) a Debian (#858872) byla nalezena bezpečnostní chyba CVE-2017-6964 zneužitelná k lokální eskalaci práv. Linuxové distribuce používající eject z balíčku util-linux nejsou zranitelné.

Ladislav Hagara | Komentářů: 14
včera 05:55 | Komunita

Dries Buytaert, autor a vedoucí projektu Drupal a prezident Drupal Association, požádal soukromě před několika týdny Larryho Garfielda, jednoho z klíčových vývojářů Drupalu, aby projekt Drupal opustil. Larry Garfield minulý týden na svých stránkách napsal, že důvodem jsou jeho BDSM praktiky a rozpoutal tím bouřlivou diskusi. Na druhý den reagoval Dries Buytaert i Drupal Association. Pokračuje Larry Garfield [reddit].

Ladislav Hagara | Komentářů: 54
včera 04:44 | Humor

Společnost SAS zveřejnila na svých stránkách studii s názvem Open Source vs Proprietary: What organisations need to know (pdf). Organizace by měly například vědět, že ideální je mix 40 % open source softwaru a 60 % proprietárního softwaru [Slashdot].

Ladislav Hagara | Komentářů: 12
27.3. 23:33 | Zajímavý software

Byl vydán ShellCheck ve verzi 0.4.6. Jedná se o nástroj pro statickou analýzu shellových skriptů. Shellové skripty lze analyzovat na webové stránce ShellChecku, v terminálu nebo přímo z textových editorů. Příklady kódů, na které analýza upozorňuje a doporučuje je přepsat. ShellCheck je naprogramován v programovacím jazyce Haskell. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv3.

Ladislav Hagara | Komentářů: 0
27.3. 23:33 | Pozvánky

Czech JBoss User Group zve na setkání JBUG v Brně, které se koná ve středu 5. dubna 2017 v prostorách Fakulty informatiky Masarykovy univerzity v místnosti A318 od 18:00. Přednáší Pavol Loffay na téma Distributed Tracing and OpenTracing in Microservice Architecture.

… více »
mjedlick | Komentářů: 0
27.3. 11:33 | Zajímavý článek

Národní centrum kybernetické bezpečnosti (NCKB) vypracovalo (pdf) 26 podrobných bezpečnostních doporučení pro síťové správce. Tato doporučení jsou nastavena tak, aby je bylo možné aplikovat v každé instituci. Jsou rozdělena na tři základní části: bezpečnost infrastruktury, bezpečnost stanic a serverů a bezpečnost uživatelů.

Ladislav Hagara | Komentářů: 17
27.3. 05:55 | Komunita

Prezident Nadace pro svobodný software (FSF) Richard M. Stallman vyhlásil na slavnostním ceremoniálu v rámci konference LibrePlanet 2017 vítěze Free Software Awards za rok 2016. Ocenění za společenský přínos získal SecureDrop (Wikipedie). Za rozvoj svobodného softwaru byl oceněn Alexandre Oliva (Wikipedie).

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 960 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    Dotaz: Java - garbage collector

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

    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: 48
    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.