[linux] java socketserver - geheugen

[Verwijderd]

Ik heb een socketserver op een windows-machine draaien. Nu willen wij deze gaan draaien op een linuxserver, maar na testen blijkt dat er problemen zijn met het opruimen van het geheugen.
Nu heb ik een voorbeeld gebruikt om te testen en blijkt dat dan het geheugen ook niet wordt opgeruimd.

Ik heb dit voorbeeld gebruikt:
http://www.javareference....les/viewexample.jsp?id=47

Heeft iemand ervaring met dit probleem, of enig idee waar ik moet zoeken.

Wij maken gebruik van een Redhat installatie, maar andere distributies maakt geen verschil

[Creepy]

En hoe test je dat het niet gebruikte geheugen wordt opgeruimd? Dit zou namelijk "af en toe" automatisch moeten gebeuren door de Garbage Collector. Wat deze vrijgeeft en wanneer bepaald de GC in principe zelf.

[Verwijderd]

Creepy schreef op dinsdag 19 december 2006 @ 11:49:
En hoe test je dat het niet gebruikte geheugen wordt opgeruimd? Dit zou namelijk "af en toe" automatisch moeten gebeuren door de Garbage Collector. Wat deze vrijgeeft en wanneer bepaald de GC in principe zelf.

Als ik op de linux-server met op het geheugengebruik bekijk (met 'top') is er bij dit eenvoudige voorbeeld al 45Mb in gebruik en dat wordt per connectie meer. Na het sluiten van een connectie (ook na een uur) is dit niet gezakt

[Gerco]

Dat zegt helemaal niets. Misschien is die JVM implementatie op linux conservatiever met het draaien van de GC. Dat doet hij waarschijnlijk pas als hij geen geheugen meer vrij heeft binnen zijn heap. Je zal in dat geval het geheugen langzaam zien stijgen tot de max heap size en dan nooit meer af- of toenemen.

Wil je zeker zijn dat de GC afgaat, zet dan ergens System.gc() neer om een garbage collection run af te dwingen. Dit zou ik echter niet in je produktiecode laten staan! Overigens is de JVM nog steeds niet verplicht om het geheugen dan weer aan het systeem terug te geven, hij kan best besluiten om die heap voor zichzelf te houden voor het geval hij het later weer nodig heeft.

[ Voor 19% gewijzigd door Gerco op 19-12-2006 12:09 ]

[Verwijderd]

Op mijn linux server trekt ie em ook helemaal vol, is niets raars aan

[Verwijderd]

Gerco schreef op dinsdag 19 december 2006 @ 12:07:
Dat zegt helemaal niets. Misschien is die JVM implementatie op linux conservatiever met het draaien van de GC. Dat doet hij waarschijnlijk pas als hij geen geheugen meer vrij heeft binnen zijn heap. Je zal in dat geval het geheugen langzaam zien stijgen tot de max heap size en dan nooit meer af- of toenemen.

Wil je zeker zijn dat de GC afgaat, zet dan ergens System.gc() neer om een garbage collection run af te dwingen. Dit zou ik echter niet in je produktiecode laten staan! Overigens is de JVM nog steeds niet verplicht om het geheugen dan weer aan het systeem terug te geven, hij kan best besluiten om die heap voor zichzelf te houden voor het geval hij het later weer nodig heeft.

Bedank voor deze tip, ik zal eens goed bestuderen of het geheugen na verloop van tijd idd niet verder op loopt

[momania]

Gerco schreef op dinsdag 19 december 2006 @ 12:07:
Wil je zeker zijn dat de GC afgaat, zet dan ergens System.gc() neer om een garbage collection run af te dwingen.

Onzin. Die methode doet alleen een suggestie/advies naar de JVM. De JVM beslist daarna nog altijd zelf of hij dat advies opvolgt. Het forceert dus geen garbage collection.

[Verwijderd]

Dit heeft waarschijnlijk iets te maken met het cache-mechanisme in linux.

[Verwijderd]

Verwijderd schreef op dinsdag 19 december 2006 @ 12:16:
Dit heeft waarschijnlijk iets te maken met het cache-mechanisme in linux.

Maar moet ik me nu zorgen gaan maken als het geheugengebruik sterk oploopt ?

[Verwijderd]

Nee, want als programma's het weer nodig hebben bouwt linux zijn cache weer af

[Verwijderd]

Verwijderd schreef op dinsdag 19 december 2006 @ 12:20:
Nee, want als programma's het weer nodig hebben bouwt linux zijn cache weer af

Dan ga ik er vanuit dat er geen problemen komen, ik zal het wel in de gaten houden, maar op windows ging het ook goed.

[Verwijderd]

Verwijderd schreef op dinsdag 19 december 2006 @ 12:22:
[...]


Dan ga ik er vanuit dat er geen problemen komen, ik zal het wel in de gaten houden, maar op windows ging het ook goed.

Linux is niet eng

[Gerco]

momania schreef op dinsdag 19 december 2006 @ 12:15:
Onzin. Die methode doet alleen een suggestie/advies naar de JVM. De JVM beslist daarna nog altijd zelf of hij dat advies opvolgt. Het forceert dus geen garbage collection.

Hmm, dat wist ik niet. Hoe dan ook, de kans dat hij het op dat moment gaat doen is groter dan wanneer je dat niet zou neerzetten, lijkt me.

Die hele gc is in dit geval niet relevant, want er is hoogst waarschijnlijk gewoon sprake van een verschil in JVM implementaties, instellingen of andere (OS-specifieke) verschillen.

[Remus]

Java alloceert heap-geheugen binnen het opgegeven maximum bij opstarten (+ nog wat geheugen voor de runtime zelf), binnen het gealloceerde heap-geheugen doet java het eigen geheugen management. Het eenmaal gealloceerde geheugen wordt in principe niet meer vrijgegeven aan het OS totdat de applicatie beëindigd is. Binnen het gealloceerde geheugen wordt gewoon garbagecollection uitgevoerd, maar daarvan merk je buiten de applicatie dus niets.

Indien nodig (en het opgegeven maximum nog niet is bereikt) zal java extra heap-geheugen alloceren.

In Windows lijkt het soms dat het gebruikte heap-geheugen van een java-applicatie afneemt, omdat de kolom 'Geheugengebruik' in de Windows taskmanager alleen de actieve geheugenpagina's toont, pagina's die in het virtueel geheugen zijn ondergebracht (omdat ze al langere tijd niet zijn gebruikt ed) worden daar niet bij opgeteld(!).

[Bobco]

Als je echt wil zien wat er aan de hand is dan hebben Java 5 en hoger een paar leuke tools in de aanbieding. Met behulp van jmap en jhat kun je een dump van de heap maken en deze vervolgens analyseren. Verder zou je ook kunnen overwegen om jconsole te gebruiken om real time te volgen wat er in de JVM gebeurt met het geheugen. Ik raad de Java 6 versie aan, die is een stuk mooier dan de vorige.