2016. szeptember 1., csütörtök

dynaTrace - Memória szivárgás beazonosítása

Az előző cikk folytatásaként, egy éles rendszerben előfordult memória szivárgáson keresztül fogom megmutatni, hogy hogyan is kell a dynaTrace-szel a gyökér okokig eljutni. Általában minden azzal kezdődik, hogy a dynaTrace-től kapunk egy riasztást, hogy kevés a szabad memória vagy túl sokat GC-zik az appserver, majd a Process Health dashboardon validáljuk, hogy valóban ez a helyzet. Restart után készítettem néhány Memory Consumption Trending dump-ot és beazonosítottam, hogy mely osztályok példány száma növekszik. Esetünkben a BasifTopup osztályból 669.195 darab volt a heap-en.


Ezután a System Profile/Sensors menüpont alatt a BasifTopup osztályra felhelyeztem egy memória szenzort. A dynaTrace hot sensor placement feature segítségével, külön újraindítás nélkül, futásidőben aktiválódott ez a szenzor szabály.


Selective Memory Dump-ok készítésével látható váltak az objektum allokációk, ahonnan pedig továbbfúrtam azokhoz a PurePath-okhoz, ahol ezek az objektum példányok létrejöttek.

A PurePath hívási láncnál megjelent, hogy a BasifTopup példányai, a registerResultInUnitOfWork() metódus hívásnál keletkeznek nagy számban. Innen két kattintással a bytecode visszafejtésével elém tárult a forráskód, ami alapján megtettem a javaslataimat a probléma elhárítása érdekében.


Hát nem egyszerű és nagyszerű? :))


2016. augusztus 6., szombat

dynaTrace - Memória dump típusok

Gyorsan meg akarod találni a memória szivárgás (memory leak) valódi okát? Használj dynaTrace-t! Attól függően, hogy milyen információra van szükséged, 3 féle heap dump típus készítése közül választhatsz:

1. Deep Memory Leak Analysis:

Ez a hagyományos heap dump-nak feleltethető meg, azaz az objektumok kapcsolatai, a referenciák mentén lekövethető. A heap méretétől függően több percbe is telhet a dump létrehozása, mialatt a JVM mással nem foglalkozik, így napközben való készítése, éles környezetben csak indokolt esetben javasolt. Az elkészített dump utófeldolgozását a dynaTrace Analysis szerver fogja elvégezni. Gyakori kérdés, de a dynaTrace-es dump-ot más eszközzel (Eclipse Memory AnalyzerIBM HA) nem tudjuk beolvasni.


2. Memory Consumption Trending:

Ezzel a dump-pal megkapjuk, hogy melyik osztályból hány példány volt a memóriában. Az előnye, hogy néhány másodperc alatt lefut, azaz nem akasztja meg az alkalmazás futását, így éles környezetben, akár napközben is használható. Ha memória fogyást tapasztalunk, készítünk pl. 10 percenként pár dumpot és összehasonlíthatjuk őket, hogy mely osztályok példányszáma növekszik folyamatosan. 


3. Selective Memory Dump:

Miután a Memory Consumption Trending dump-ok készítésével meghatároztuk azokat az osztályokat, amelyek példányszáma növekszik, ezen az osztályokra memória szenzort tehetünk fel, majd a Selective Memory Dump készítésével megtekinthetjük, hogy a PurePath hívási láncban ezek az objketumok melyik metódusnál jönnek létre. Nagyon hasznos feature!


A folytatásban pedig egy esettanulmányt fogok megmutatni, hogy a gyakorlatban hogyan kell egy memory leak gyökér okát beazonosítani a dynaTrace-szel.

2016. július 24., vasárnap

EMA and Plumbr - Memory leak hunting

Hogy ne mindig csak a dynaTrace-ről legyen szó, most az Eclipse Memory Analyzer-rel és a Plumbr eszközökkel mutatom meg, hogyan lehet megoldni egy memória szivárgást. Egy web-alkalmazásnál tapasztaltam azt a jelenséget, hogy néhány undeploy-deploy művelet hatására java.lang.OutOfMemoryError: PermGen space hiba keletkezett. A szokásostól eltérően, most nem a dynaTrace-t vettem elő (mert az adott szerveren nem volt DT licence) hanem más alternatívákat.

Az OutOfMemory hatására készült egy heap dump, amit betöltöttem az EMA eszközbe. Itt van egy jó tutorial az EMA-val való ClassLoading leak megtaláláshoz. A megoldáshoz nem kellett sokat keresgélni, mert már a beépített Leak Suspect Report is kimutatta, hogy hol lesz a probléma, mindenesetre azért kicsit magam is megnézegettem a dumpot, ahol bebizonyosodott, hogy az oracle jdbc driver miatt, az osztálybetöltő nem tudott felszabadulni.


Már rég kiakartam próbálni a java agnet alapú Plumbr free verzióját, ezért ez a memory leak pont kapóra jött nekem. A Plumbr nem az utólag elkészített heap dump-ot analizálja, hanem real-time figyeli az alkalmazásunkat és ha egy anomáliát talál, azonnal kijelzi a probléma okát és még megoldási javaslatokkal is ellát minket. Ezt már nevezem!


Itt, itt meg itt találtam néhány leírást ami pontosan illeszkedett erre a problémára, röviden tehát a leak-et az okozta, hogy az adatbázis driver nem került sohasem felszabadításra egy WildFly bug miatt, amit az osztálybetöltési policy módosításával sem sikerült orvosolni. Végül, más megoldás hiányában - egy nem szép - de működő programozott megoldást próbáltam ki amivel megoldódott a hibajelenség.


Jut eszembe, a Java 8-ban már nincs is perm gen space helyette van metaspace. :)