Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Chico Hau at 10:08 on Wednesday 9 April    Add 'Understanding and Tuning the Java Virtual Machine' site to delicious  Add 'Understanding and Tuning the Java Virtual Machine' site to technorati  Add 'Understanding and Tuning the Java Virtual Machine' site to digg  Add 'Understanding and Tuning the Java Virtual Machine' site to dzone

Met regelmaat komt het voor dat een systeem wordt opgeleverd en dat blijkt dat dit systeem niet voldoet aan de non-functional requirements performance. Hoe kunnen we zorgen dat het systeem weer beter gaat presteren? Als eerste kunnen we er meer hardware onder zetten zoals snellere processoren, meer geheugen, meer disk etc. Dit is over het algemeen geen goede oplossing omdat de oorzaak van de performancehit hiermee niet achterhaald wordt. Het is meer een brute kracht oplossing.

Ten tweede kan onderzocht worden hoe efficient de programmatuur geschreven is. Dit is een betere oplossing en hiervoor zijn een aantal programming best practices verzameld:

  • onderzoek welke quick wins te behalen zijn, veel kleine optimalisaties kosten tijd en kunnen te weinig performancewinst opleveren
  • kijk kritisch naar het aanmaken van nieuwe objecten en vermijd creatie van onnodige objecten
  • gebruik debug, trace en loggingcode, maar probeer de overhead van logging zo minimaal mogelijk te houden
  • verwijder onnodige en ongebruikte code; dit zorgt voor langere laadtijden van de classes door de classloader

Er zijn ook goede tools beschikbaar om de programmatuur te kunnen analyseren, zoals het Eclipse Test and Performance Tools Platform Project (http://www.eclipse.org/projects/project_summary.php?projectid=tptp).

Een andere optie waar niet zo snel aan gedacht wordt, maar zeker net zo belangrijk is is het tunen van de JVM. Deze presentatie heeft het verschil gemaakt tussen de IBM JVM en de Sun JVM, deze zijn niet helemaal gelijk. IBM heeft een aantal wijzigingen aangebracht in de Sun JVM, maar in de kern zijn zij nog gelijk. Gelukkig worden hier van beide JVM’s de opties aangegeven. Om de JVM de kunnen tunen, is diepgaande kennis nodig van hoe de JVM omgaat met bijvoorbeeld memory management, garbage collector en heap management; de settings worden net zolang verfijnd totdat de optimale instelling is gevonden.
Welke zaken kunnen we doen om de JVM beter te laten presteren?

  • Zorg dat de garbage collector (GC) zo efficient mogelijk opereert. De GC is een systeem dat de door de applicatie aangemaakte objecten, waar geen referenties meer naar verwijzen, opruimt en het geheugen hiervoor weer vrijgeeft. De GC loopt fysiek langs elk object in de heap om te kijken of deze nog wordt gebruikt. Er zijn verschillende algoritmes mogelijk op welke wijze over de heap heen gelopen wordt; het algoritme kun je aan de JVM als parameter meegeven. Als garbage collecting wordt uitgevoerd ligt het systeem stil totdat de GC klaar is, het is dus belangrijk om dit goed af te stellen dat de GC alleen loopt als het echt nodig is. Tip: gebruik de JVM optie -verbose:gc (standaard aanwezig). Deze logging geeft veel informatie over de GC om threads en heaps te analyseren. Deze uitgebreide logging kan met tools worden geanalyseerd zoals met de grafische tool ThreadAnalyzer.
  • Maak thread dumps, dit zijn in feite momentopnamen en geven een beeld waar het systeem op dat moment mee bezig is. Dit verschaft veel informatie over bottlenecks en veel uitgevoerde methoden. De threaddump kan ook met behulp van ThreadAnalyzer worden geanalyseerd.
  • Heapsize optimalization and tuning: sinds JDK 1.4.1 is een nieuwe JVM setting geintroduceerd waarmee automatisch de beste instellingen voor de heap op het systeem worden gebruikt (-XX:+AggressiveHeap i.c.m. -server parameter). Het is ook mogelijk om dit zelf met diverse parameters te tunen.

Deze instellingen zullen per applicatie en per systeem verschillen. Om die reden dient het bovenstaande proces een aantal malen te worden uitgevoerd, om zo tot de optimale instelling te komen.


© 2020 Java Competence Network. All Rights Reserved.