CONFIGURARE UNA JVM IN HYPERIC Abilitare il

CONFIGURARE UNA JVM IN HYPERIC
Con Hyperic è possibile configurare una JVM per far si che l’agent possa inviare informazioni
riguardanti la machine al server Hyperic; per fare questo bisogna come prima cosa abilitare il
monitoraggio JMX sulla Java Virtual Machine, dopo dobbiamo fare in modo che il server Hyperic
possa “leggere” le informazioni che invia l’agent.
Abilitare il JMX remote monitoring
La prima cosa da fare è far si che la nostra JVM possa essere monitorata in remoto, per far questo
basterà semplicemente abilitare il JMX (Java Management EXtensions) e poi l’agent penserà a
inviare i dati al server.
Per abilitare il JMX bisognerà allo start della nostra JVM (o quando startiamo la nostra
App)impostare questa proprietà:
com.sun.management.jmxremote
Questa proprietà registra la strumentazione della JVM in dei bean e pubblica un connettore RMI
tramite un’interfaccia privata per permettere al client JMX di monitorare in remoto la JVM.
Per esempio se abbiamo una App chimata NostraApp dovremo:
java -Dcom.sun.management.jmxremote -jar NostraApp.jar
Dovremo anche configurare una “porta” di comunicazione per poter leggere i dati in remoto e
possiamo fare questo impostando anche questa proprietà:
com.sun.management.jmxremote.port=[numeroPorta]
Di default il JMX agent utilizza una password di autenticazione e anche una certificazione SSL, ma
nei nostri test li abbiamo disabilitati entrambi utilizzando i rispettivi comandi:
com.sun.management.jmxremote.authenticate=false
com.sun.management.jmxremote.ssl=false
Per maggiori informazioni sulle alter proprietà JMX è possible usufruire della guida messa a
disposizione da oracle al seguente link.
Configurare la JVM su Hyperic
Come primo passo dobbiamo configurare manualmente un nuovo server, il quale sarà la nostra
JVM da monitorare; per fare questo dobbiamo entrare nella schermata della risorsa nella quale
abbiamo configurato la JMX. Da questa pagina dobbiamo cliccare su Tools Menu  New Server e
avremo una schermata come la seguente:
In questa schermata dobbiamo mettere il Name che sarà il nome del server che andremo a
installare; da una combo box dobbiamo scegliere la tipologia di server (nel nostro caso andremo a
scegliere Sun JVM 1.5, tale opzione vale per tutte le versioni di JVM dalla 1.5 in poi) e come ultimo
campo dobbiamo dichiarare il path di installazione del server, nel nostro caso:
“C:\Program Files (x86)\Java\jdk1.6.0_23”.
Dopo ciò ci troveremo in una schermata di riepilogo, come quella seguente, dove dovremo
impostare il server JMX, e lo possiamo fare cliccando su Configuration Properties:
Qui dovremo configurare il jmx.url impostandolo:
service:jmx:rmi:///jndi/rmi://<IP_JVM>:<NumPorta>/jmxrmi
Dove l’IP dovrà essere quello della macchina dalla quale vogliamo monitorare la JVM, mentre il
NumPorta sarà il numero della porta che abbiamo impostato nelle proprietà del JMX.
Ritornando nella lista dei server della nostra piattaforma troveremo il nuovo server con il nome
che avevamo impostato precedentemente.
Entrando nella schermata avremo due servizi attivi, il Garbage Collector e il Memory Pool e
saranno gli stessi servizi che potremmo monitorare tramite la JConsole.
Notiamo che entrando nella parte della JVM Memory pool troveremo altre “sottosezioni” che non
solo altro le varie tipologie in cui è divisa la memoria gestita dalla JVM; potremmo dividerla in 2
grandi gruppi, la memoria di heap e quella di non-heap.
Queste due “tipologie di memoria sono a loro volta suddivise:
- Memoria di Heap (dove si memorizzano i Java Object)
o Eden Space;
o Survivor Space;
o Tenured Generation;
- Memoria di non-heap (dove si salvano le classi e gli altri meta-dati)
 Shared read-only area
o Permanent Generation
 Shared read-write area
o Code Cache
La Eden Space è la memoria in cui vengono allocati gli oggetti all’inizializzazione della JVM; dopo
un primo passaggio della Garbage Collector gli oggetti che “sopravvivono” sono memorizzati nella
Survivor Space , mentre nella Tenured Generation sono contenuti gli oggetti che sono stati nella
Survivor Space.
Mentre la non-heap memory è suddivisa in Permanent Generation che contiene tutti i dati relativi
alla JVM stessa come come classi e metodi; questa area è suddivisa in due aree una di sola lettura
e una di lettura e scrittura. La Code Cache contiene la memoria che viene utilizzata per la
compilazione e la memorizzazione del codice nativo.
The memory tab allows you to see the amount of memory used by each region, or space, in the
heap. The heap is divided into the following spaces:
 Eden Space: part of the young generation, the Eden space is where all objects are created
(after all everything was created in the garden of Eden)

Survivor Space: there are two identically sized survivor spaces in the young generation that
are used to perform copy garbage collections. When the garbage collector runs it attempts
to copy live objects from Eden and one of the survivor spaces to the other survivor space. If
the second survivor space fills up before all live objects can be copied into it then the
remaining objects are tenured or copied to the tenured space (in the old generation)

Tenured Generation: this is the old generation of the heap that holds long lived objects or
prematurely tenured objects. Tenured objects can only be reclaimed by performing a mark
and sweep garbage collection, which is an expensive operation and typically freezes all
execution threads

Code Cache: non-heap memory used for compilation and storage of native code

Permanent Generation: non-heap memory used to maintain JVM process objects, such as
class files and methods. Consider that before you can create a class instance on the heap,
the JVM needs to open the ".class" file to determine what that object looks like — that class
definition is stored in the permanent space
Per ogni altra informazione fare riferimento alla documentazione Oracle qui.
Nella sezione della JVM Garbace Collector possiamo notare altri due servizi attivi:
- JVM (minor) Copy Garbage Collector
- JVM (major) MarkSweepCompact Garbage Collector
La Copy si può definire lo “spazzino veloce” che, in presenza di thread in esecuzione, raggruppa
tutti i dati che sono attivi nell’heap; mentre la Mark Sweep Compact è più intrusiva, che sospende
tutti i thread in esecuzione mentre completa il suo compito (segnare, spazzare, compattare).
An additional advantage to the knowledge that objects die quickly in this area, we can also skip the
compacting step and do something else called copying. This means that instead of seeking free areas
(by seeking the areas marked as unused after the marking step), we copy the live objects from one
young generation area to another young generation area. The originating area is called the From
area, and the target area is called the To area, and after the copying is completed the roles switch:
the From becomes the To, and the To becomes the From.
Spiegazione della Copy Garbage Collector
The mark-and-sweep algorithm is called a tracing garbage collector because is traces out the entire
collection of objects that are directly or indirectly accessible by the program. The objects that a
program can access directly are those objects which are referenced by local variables on the
processor stack as well as by any static variables that refer to objects. In the context of garbage
collection, these variables are called the roots . An object is indirectly accessible if it is referenced by
a field in some other (directly or indirectly) accessible object. An accessible object is said to be live .
Conversely, an object which is not live is garbage.
The mark-and-sweep algorithm consists of two phases: In the first phase, it finds and marks all
accessible objects. The first phase is called the mark phase. In the second phase, the garbage
collection algorithm scans through the heap and reclaims all the unmarked objects. The second
phase is called the sweep phase. The algorithm can be expressed as follows:
for each root variable r
mark (r);
sweep ();
In order to distinguish the live objects from garbage, we record the state of an object in each object.
That is, we add a special boolean field to each object called, say, marked. By default, all objects are
unmarked when they are created. Thus, the marked field is initially false.
Spiegazione della MarkSweepCollect Garbage Collector