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

2016. július 15., péntek

Arduino Uno - Szenzor projekt

A Raspberry Pi mini számítógépem mellé vettem pár hónapja egy Arduino-t és néhány szenzort is az elektronikai kísérletezéshez. Az Aliexpressz-ről rendeltem meg a cuccokat, így kb. 4000Ft-ért kaptam egy Arduino UNO klónt USB kábellel, egy PIR mozgásérzékelőt, egy DHT-22 nagy pontosságú hőmérséklet és páraszenzort valamint egy HCR-SR04 ultrahangos távolságmérőt. A célom az volt, hogy a szenzorok által begyűjtött mérési eredmények a fejlesztő eszköz konzolján megjelenjenek.


Az alábbi programot készítettem el, majd feltöltöttem az Arduino-ra. A kódban definiáltam a szenzorok lábait, amelyekről a mérési eredmények beolvashatók, majd a Serial.print() hívással egyszerűen kiírattam ezeket a konzolra.
#include "DHT.h"

#define DHTPIN 2
#define DHTTYPE DHT22
DHT dht(DHTPIN, DHTTYPE);
 
int triggerPin = 11;    
int echoPin = 12;   
long durationMicroSec,cm;

int pir=4;

void setup() {
  Serial.begin (9600);
  
  //HCSR04
  pinMode(triggerPin, OUTPUT);
  pinMode(echoPin, INPUT);
  
  //DHT22
  dht.begin(); 
    
  //PIR
  pinMode(pir, INPUT); 
}
 
void loop()
{  
  //HCSR04
  digitalWrite(triggerPin, LOW);
  delayMicroseconds(5);
  digitalWrite(triggerPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(triggerPin, LOW);

  durationMicroSec = pulseIn(echoPin, HIGH);
  cm = (durationMicroSec*0.000001*34300)/2.0; //s=v*t

  Serial.print(cm);
  Serial.print("cm");
  Serial.println();
    
  //DHT22
  delay(2000);
  float h = dht.readHumidity();
  float t = dht.readTemperature();
  if (isnan(h) || isnan(t)) {
    Serial.println("Failed to read from DHT sensor!");
    return;
  }
  Serial.print("Humidity: "); 
  Serial.print(h);
  Serial.print(" %\t");
  Serial.print("Temperature: "); 
  Serial.print(t);
  Serial.print(" *C ");
  Serial.println();
  
  //PIR
  if(digitalRead(pir)){      
      Serial.print("There is motion");
  }
  else{
      Serial.print("There is no motion");
  }
  Serial.println();  
}
Az Ardunio használatával, pár ezer forintból akár egy komplex otthoni biztonsági rendszert is kialakíthatunk. Ha lecsupaszítjuk az Ardunino-t a felesleges elektronikai részektől, akkor egy akkumulátorról akár több hónapig is képes a működésre. A mért jellemzőket pl. rádió frekvenciás csatornán (szintén pár 100Ft-os áramkör) egy Raspberry Pi-nek is továbbíthatjuk, amivel feldolgozhatjuk és eltárolhatjuk a mért adatokat. A lehetőségeknek nem a pénztárcánk, hanem csak a képzeletünk szabhat határt! :)