[Java] Tuning van de JVM

[-FoX-]

JVM overzicht
• Java is een 'Write Once Run Anywhere' OO taal die uitgevoerd wordt op een virtuele machine.
• De Java Virtual Machine (JVM) voert applicaties, die geschreven zijn in Java, uit nadat deze Java code gecompileerd werd naar bytecode door het 'javac' proces.
• De JVM voert, samen met een aantal andere componenten, optimalisaties uit op de gecompileerde Java code om deze nog sneller te kunnen uitvoeren.
• De JVM zorgt automatisch voor het geheugen (Garbage Collection) zodat het voor de developers makkelijker wordt om ervoor te ontwikkelen en dat het risico om memory leaks beperkt blijft.
• Er zijn meerdere implementaties van de JVM, met een eigen set aan instellingen.
De JVM's core runtimes zijn ontwikkeld in C/C++ en voeren dan ook een groot deel van de functies uit in native code, zoals GC, MMU, JIT, OS calls, IO subroutines, ... De J2SE/J2EE API bestaat op Java code niveau.

Classloader overzicht
• Laden - De bytecode bekomen van een Java class bestand
• Verificatie - Valideert de code binnen de class (geen illegale operaties in de JVM, corrupt, ...)
• Voorbereiding - Allocatie en initializatie van ruimte voor de static members
• Initializatie - Voert de initializatie code van een class uit en initialiseert static fields

JIT overzicht
De just-in-time compiler (JIT) is niet echt een onderdeel van de JVM, maar is wel essentieel voor een snel werkende Java applicatie. De JIT werkt door het compileren van bytecode, geladen door de classloader, wanneer deze aanroepen wordt.

Memory Management
Garbage Collection is een van de hoofdoorzaken van geheugen gerelateerde performance problemen in Java. 2 zaken moeten altijd in het achterhoofd gehouden worden bij GC:
- Frequentie: hangt af van de heap size en allocatie ratio
- Duur: hangt af van de heap size en de Java heap footprint

---

Na deze korte intro, vraag ik me af hoe de meerderheid hier te werk gaat om zijn JVM af te stellen op zijn applicatie.
• Welke methodes pas jij toe? (stap-voor-stap)
• Waar haal jij de meeste performance winsten uit?
• Wat zijn de richtlijnen waarmee jij rekening probeert te houden?

De eerste techniek die ik meestal probeer toe te passen in
1. Heap size tuning (-Xms -Xmx)
- Frequentie: max. om de 10s
- Duratie: max. 2s
tip: Voor het bepalen van een goede heap size; kan je het gemiddelde van de applicatie + 30% nemen.

-XX:+AggresiveHeap: nieuwe setting (JDK1.4.1+), en voorziet in het automatisch tunen van de heap settings (GC algorithm, Young/Old generation spaces, etc...)

2. Runtime optimalisaties
-server: efficiënter voor applicaties met CPU intensieve taken
-XX:+UseParallelGC: Betere performance op machines met veel CPUs (4+)
-XX:+UseConcMarkSweepGC: Constantere response tijden op machines met veel CPUs (4+)
-XX:+UseTrainGC: Constantere response tijden op machines met weinig CPUs

3. Repeat 1.

"Meten is weten"
Alles is gebaseerd op goede applicatiestatistieken. Als je bijvoorbeeld meer wil teweten komen over de GC van je applicatie; is het voldoende om volgende optie aan je JVM mee te geven:
-verbose:gc of -Xloggc:<file> -XX:+PrintGCDetails

Verder zijn er nog een aantal commerciële tools zoals JProfiler, JMeter, ...
Meer info kan je ook terugvinden op javaperformancetuning.com

[Gerco]

Ik doe veel XML transformaties met grote XML bestanden en mijn JVMs hebben dus vaak *veel* geheugen nodig, maar slechts een paar seconden tot minuten. Meestal draaien er meerdere JVMs op 1 machine die grotendeels hetzelfde doen.

Ik heb nu een probleem met -Xmx, aangezien ze toch soms wel eens >1GB geheugen nodig hebben, maar er niet genoeg RAM in de machine zit om ze allemaal 1GB te geven. De JVM neemt niet meteen alle geheugen in beslag wat je met -Xmx toewijst, maar hij checkt wel iets, aangezien hij weigert op te starten boven de 1200 MB (ongeveer) met een "unable to allocate heap ... " error.

Wat zou ik hiermee kunnen doen, ik wil eigenlijk helemaal geen geheugenmaximum aangeven, net zoals ik dat bij andere processen niet hoef te doen. Gebruik gewoon alles wat de machine heeft en geef het weer terug als je het niet meer nodig hebt. Is dat nu zo moeilijk?

[MTWZZ]

Is er bij Java ook de mogelijkheid om de JVM te hosten binnen je eigen app? Als dat zo is zou je de transformatie apart kunnen uitvoeren binnen een eigen instantie van de JVM die dan veel geheugen pakt. Als de transformatie is afgelopen kun je die opruimen en is de ruimte weer beschikbaar voor andere processen.

[Gerco]

Helaas, dat is niet mogelijk aangezien ik de App niet heb geschreven. Het is een out-of-the box produkt (Sonic ESB) waar mijn code in draait, wat de transformaties uitvoert en waar ik mijn probleem mee heb. Ik heb net het volgende gevonden:

quote: http://www.unixville.com/~moazam/

Usually we don't have trouble getting modest contiguous regions (up to about 1.5GB on Windohs, up to about 3.8GB on Solaris. YMMV.).

Groter dan 1.5GB zal het op 32 bit Windows toch niet worden, ongeacht switches omdat het design van de JVM dat momenteel niet toelaat. Als we daar regelmatig overheen gaan wordt het eens tijd om over te stappen op een 64 bit OS (Windows of Linux, boeiuh).

[Cuball]

Ik vind het leuk dat dit je dit topic aanhaalt, wij zijn namelijk op een punt gekomen waar we toch gaan moeten kijken wat er allemaal kan getuned worden qua geheugen configuratie.

We hebben nu zo'n 7 applicaties op één tomcat server draaien. Ik vroeg me af hoeveel geheugen applicaties bij andere bedrijven gaan gebruiken, ik heb de maximum memory pool op 896 MB gezet, initieel op 256MB en max permsize eveneens op 256MB.

volgende stats heb ik bij de server:

code:

JVM
Free memory: 93.91 MB Total memory: 254.18 MB Max memory: 889.12 MB

http-80
Max threads: 150 Min spare threads: 25 Max spare threads: 75 Current thread count: 50 Current thread busy: 5
Max processing time: 19047 ms Processing time: 4407.798 s Request count: 45989 Error count: 3131 Bytes received: 7.73 MB Bytes sent: 700.69 MB

daarbij moet je weten dat we er zeker nog 5 extra toepassingen moeten bijzetten (toepassingen die nu getest worden en klaar zijn voor deployement). Ik zal hier dus zeker en vast tegen een geheugen probleem aanlopen.

[-FoX-]

Cuball schreef op woensdag 22 november 2006 @ 13:13:
Ik vind het leuk dat dit je dit topic aanhaalt, wij zijn namelijk op een punt gekomen waar we toch gaan moeten kijken wat er allemaal kan getuned worden qua geheugen configuratie.

We hebben nu zo'n 7 applicaties op één tomcat server draaien. Ik vroeg me af hoeveel geheugen applicaties bij andere bedrijven gaan gebruiken, ik heb de maximum memory pool op 896 MB gezet, initieel op 256MB en max permsize eveneens op 256MB.

volgende stats heb ik bij de server:

code:

JVM
Free memory: 93.91 MB Total memory: 254.18 MB Max memory: 889.12 MB

http-80
Max threads: 150 Min spare threads: 25 Max spare threads: 75 Current thread count: 50 Current thread busy: 5
Max processing time: 19047 ms Processing time: 4407.798 s Request count: 45989 Error count: 3131 Bytes received: 7.73 MB Bytes sent: 700.69 MB

daarbij moet je weten dat we er zeker nog 5 extra toepassingen moeten bijzetten (toepassingen die nu getest worden en klaar zijn voor deployement). Ik zal hier dus zeker en vast tegen een geheugen probleem aanlopen.

Waarom heb je de maxPermSize zo hoog gezet?

[Cuball]

-FoX- schreef op woensdag 22 november 2006 @ 21:11:
[...]

Waarom heb je de maxPermSize zo hoog gezet?

omdat die regelmatig out of memory liep, zeker nadat er een applicatie gedeployed werd...

hier moet ook nog eens gekeken worden wat er aan gedaan kan worden, maar wegens tijdsgebrek voorlopig gewoon wat hoger gezet.

Volgens mij is de hoofdreden dat deze vol loopt omdat we teveel libraries telke malen herhalen in onze projecten, terwijl deze evengoed in de common folder van tomcat zelf zou kunnen staan. Onze lib folder per project is zo'n 20MB groot, wat met zich mee brengt dat er heel wat klasses geladen moeten worden en dus het Permanent Generation geheugen snel volloopt.

[djc]

Ik vraag me af in hoeverre je Java-code met gcj op Windows kan draaien...

[ Voor 3% gewijzigd door djc op 23-11-2006 10:12 ]

[matthijsln]

Cuball schreef op donderdag 23 november 2006 @ 09:16:
[...]


omdat die regelmatig out of memory liep, zeker nadat er een applicatie gedeployed werd...

hier moet ook nog eens gekeken worden wat er aan gedaan kan worden, maar wegens tijdsgebrek voorlopig gewoon wat hoger gezet.

Volgens mij is de hoofdreden dat deze vol loopt omdat we teveel libraries telke malen herhalen in onze projecten, terwijl deze evengoed in de common folder van tomcat zelf zou kunnen staan. Onze lib folder per project is zo'n 20MB groot, wat met zich mee brengt dat er heel wat klasses geladen moeten worden en dus het Permanent Generation geheugen snel volloopt.

Wij hebben er inderdaad ook veel last van. Elke keer bij het deployen van een webapp wordt de perm gen usage groter. De precieze oorzaak of oorzaken zijn lastig te achterhalen. Blijkbaar zijn er bij het undeployen nog referenties naar de classloader van Tomcat. Log4j schijnt een boosdoener te zijn geweest, maar nog steeds zijn er memory leaks.

Hier bijvoorbeeld een grafiekje (gemaakt met rrdtool, jvmstat en cron) van de perm gen utilization van een van onze Tomcat servers van een paar maanden. Heel duidelijk zijn de deployments en restarts te zien:



Binnenkort maar weer eens restarten, anders crasht ie weer wanneer de permgen zn max heeft bereikt.

[momania]

PermGen space is een probleem waar ik ook iedere keer tegen aan loop. Log4j was niet de boosdoener maar commons logging voor zover ik weet. Ik heb hier een tijd terug dagen naar lopen zoeken, maar ben er nog steeds niet uit. Volgens mij was er ook een probleem met servlet referenties die niet opgeruimd worden. Hoop er iig snel nog een keer een oplossing voor te vinden, want het iedere keer herstarten van je Tomcat/Jboss wordt je ook gek van.

Verdere optimalitaties van de JVM zelf hou ik me niet zo mee bezig. We hebben hier een niet zo heel erg grote omgeving die draait op een Sun machine. Qua performance hebben we nog geen problemen ondervonden, dus ga ik er ook weinig tijd in steken om iets te verbeteren dat geen issue is

[misfire]

• Welke methodes pas jij toe? (stap-voor-stap)

1. Probeer duidelijke requirements te krijgen voor performance. Wat wordt het max aantal gebruikers, minimale responstijd, aantallen in gegevenssets, schaalbaarheid/betrouwbaarheid, enz.
2. Hou tijdens het design rekening met performance. Waar worden dure operaties uitgevoerd, waar wordt geheugen vastgehouden, waarom? Cachen is het laatste redmiddel, en zeker niet altijd een verbetering!
3. Stel geautomatiseerde performance testen op.
4. Af en toe profilen om onverwachte allocatie-haarden op te sporen.

De enige JVM parameter waar ik verder aan friemel is de max. heap. Andere parameters ontaarden al snel in micro-benchmarken: de standaard instellingen zijn al aardig self-tuning en over het algemeen de beste all-round.

• Waar haal jij de meeste performance winsten uit?

Verreweg de meeste winsten zijn voor mij te halen met een goed design, tunen van applicatie-logica en remoting.

• Wat zijn de richtlijnen waarmee jij rekening probeert te houden?

HttpSession is evil.
Caching is evil.
Remoting is evil.
Stateless is good.
Immutable is good.
Worker objects is good.
Synchronized is bad (maar niet weglaten voor performance, omheen designen met worker objects).

[Gerco]

misfire schreef op donderdag 23 november 2006 @ 21:52:
Worker objects is good.
Synchronized is bad (maar niet weglaten voor performance, omheen designen met worker objects).

Explain please. Hoe werkt dit in grote lijnen en waar kan ik er meer over vinden? Ik ben bezig wat meer van multithreading te leren, dus elke informatie is goed

[RobIII]

Tikje richting DTE ( Waar hoort mijn topic? )

[ Voor 59% gewijzigd door RobIII op 24-11-2006 01:28 ]

[bloody]

momania schreef op donderdag 23 november 2006 @ 14:18:
PermGen space is een probleem waar ik ook iedere keer tegen aan loop. Log4j was niet de boosdoener maar commons logging voor zover ik weet.

Dat klopt. Zie ook hier en hier voor meer informatie.

Je kunt er een beetje omheen hacken door een

code:

LogFactory.release(Thread.currentThread().getContextClassLoader());

te doen in je ServletContextListener.contextDestroyed methode, maar dit is niet erg fijn

[Cuball]

Weet iemand hoe het komt dat Code-Cache blijft stijgen ? Voorlopig is hij nog niet out of memory gegaan, maar zoals je kan zien zal dit niet zo lang meer duren