# Speicher Problem bei grossem Heap



## nollario (17. Jun 2004)

Hallo!

Ich arbeite an einer Applikation, die mit 1024 MB Speicher gestartet wird... Das ganze läuft ganz nett... Allerdings stelle ich nach eingen StundenLaufzeit fest, dass Speicher immer knapper wird bis schliesslich


```
OutOfMemoryError
```

auftaucht. Kann das sein, dass das an der VM bzw am Garbage Collector liegt? Anscheinend haben wir nämlich schon darauf geachtet, dass nicht mehr benötigte Ressourcen freigegeben werden (z.B. durch explizites Setzen auf null).

Ist es möglich, das Java mit so einem grossen Speicher Probleme hat?


----------



## Grizzly (17. Jun 2004)

Ich würde sagen, dass ihr vielleicht doch nicht alle Referenzen auf null gesetzt habt. Es gibt Konstruktionen, bei denen man nicht auf anhieb sieht, dass sie Referenzen nicht wieder freigeben. Ich würde das Teil mal durch den Profiler jagen oder Debuggen. Vielleicht mal in die Finalizer einiger Klasse ein paar Debugging-Meldungen einbauen.


----------



## L-ectron-X (17. Jun 2004)

Ich hatte mal etwas sehr ähnliches gefragt. Dort war man der Meinung, dass das auf null setzen von Objekten den Speicher nicht freigeben würde: http://www.java-forum.org/de/viewtopic.php?t=5527
Hm, in mir lodert nun wieder die Frage auf... ???:L


----------



## Beni (17. Jun 2004)

Es kann ja sein, dass ein Objekt eigentlich von niemandem mehr benötigt wird, aber dass dennoch irgendwo noch eine Referenz auf das Objekt zeigt. Dann kann es sinnvoll sein, dass diese letzte Verbindung noch gekappt wird, damit der GC mit seiner Arbeit beginnen kann.


----------



## nollario (18. Jun 2004)

hab mir auch mal alles mögliche zum thema reingezogen: verwendete algorithmen für den gc/ struktur des heap...

ein auf null setzen ist nicht nötig, forciert aber das garbage collecting.

problem ist:
(ohne es beweisen zu können) solange meine applikation nur die hälfte des zur verfügung gestellten speichers verwendet, arbeitet das gc ordentlich. stelle ich meine konfiguration so, dass der speicher komplett erschöpft wird und dreh dann wieder runter, scheint die vm nicht in der lage zu sein, wieder ressourcen frei zu schaufeln!

kann das sein?
(habe zu diesem zeitpunkt keine OutOfMemoryError Meldung - also noch kein Fehler, aber kurz davor ;-) )


----------



## Grizzly (18. Jun 2004)

nollario hat gesagt.:
			
		

> [...]stelle ich meine konfiguration so, dass der speicher komplett erschöpft wird und dreh dann wieder runter, scheint die vm nicht in der lage zu sein, wieder ressourcen frei zu schaufeln![...]



Versteh ich jetzt nicht  :bahnhof: Wie drehst Du da was rauf und runter? Denn maximalen Heap-Speicher gebe ich doch beim Start der VM an, oder?


----------



## nollario (18. Jun 2004)

durch konfiguration der anwendung zur laufzeit...

vieles funktioniert queue basiert und ich kann die grösse der queues zur laufzeit ändern... damit ändert sich dann auch der speicherbedarf zur laufzeit


----------



## Grizzly (18. Jun 2004)

Kann es dann nicht sein, dass das Problem in den Queues steckt? Das diese denn Speicher beim runterregeln nicht mehr freigeben (bzw. die Referenzen auf die Objekte).


----------



## nollario (18. Jun 2004)

nollario hat gesagt.:
			
		

> problem ist:
> (ohne es beweisen zu können) solange meine applikation nur die hälfte des zur verfügung gestellten speichers verwendet, arbeitet das gc ordentlich. stelle ich meine konfiguration so, dass der speicher komplett erschöpft wird und dreh dann wieder runter, scheint die vm nicht in der lage zu sein, wieder ressourcen frei zu schaufeln!



kann sein, aber meine vermutung ist (s. zitat) eine andere


----------



## Grizzly (18. Jun 2004)

nollario hat gesagt.:
			
		

> nollario hat gesagt.:
> 
> 
> 
> ...


Das kann ich aber fast nicht glauben. Ich habe zwar bisher keine Client-Software geschrieben, die soviel Speicher brauch. Aber JSP/Servlets auf einem Tomcat-Server mit guter Auslastung verbrauchen bestimmt auch so viel Speicher. Und da hab' ich bisher noch nie von solchen Problemen gehört. ???:L

Wie gesagt: Ich würde das mal versuchen zu profilen bzw. zu debuggen (auf gut Denglisch  ).


----------



## nollario (18. Jun 2004)

ich hab ach schon webandwendungen/ j2ee anwendungen programmiert, da hat allerdings ein einzelner server node nicht so viel heap benötigt.... wie gesagt, aber 1GB wird es eng... profiling habe ich schon gemacht und die phänomene, die man so feststellt sprechen eine sprache, die das vm als problem darstellt.


----------



## nollario (19. Jun 2004)

sooooooo... allmählich wirds traurif... habe ALLE (!!!) und das sind nicht wenige konfigurationen für die vm von sun unter solaris os bezüglich gc ausprobiert... kaum erfolg!!!!

und jetzt kommts: aufruf von 
	
	
	
	





```
System.gc();
```
 alle 5 minuten und das progrämmchen schnurt wie eine katze ohne irgendwelche probs.... speicher wird wieder ordentlich freigegeben und alles ist prima... bin da schon etwas enttäuscht, da die vm das auch alleine hinbekommen sollte. anscheinend ist sie bei größeren speichermengen einfach nicht schell genug mit dem wegräumen...


----------



## Roar (19. Jun 2004)

hehe sieh mal einer an  :toll:  :toll: 
gut zu wissen dass das ding doch was nützt


----------



## nollario (19. Jun 2004)

ja, aber eigentlich find ich es nicht so toll, dass man nun doch wieder die objekt leichen "händisch" entfernen muss - das ist sache der vm, sonst hätte man auch bei c++ bleiben können....


----------



## Grizzly (19. Jun 2004)

Gut, dass die VM nicht ständig den Garbage Collector laufen lässt, ist klar. Aber das er in einer Periode von mehr als 5 Minuten läuft ist schon merkwürdig. Und vor allem sollte die VM ihn doch wenigstens kurz bevor der freie Heap voll weg ist starten.


----------



## nollario (20. Jun 2004)

er läuft ja schon, aber er kommt vom tempo her nicht hinterher... speicherplatz wird schneller benötigt, als er freigegeben wird, deswegen gibt es bei mir immer mal solche knappheiten. ich dachte, ein = null setzen (dereferenzieren) würde zum zügigen wegräumen durch die vm führen, aber das ist wohl ein irrglaube


----------

