Java - OutOfMemoryError beim Parsen

[doi_project]

Hallo wiedermal!


Ich arbeite an einem SAX Parser, der verschiedene Metadatenwerte aus einer riesigen Datenbank herausliest und ausgibt.

Die Datenbank ist in zahlreiche Pages eingeteilt, wobei ich immer den Access-Token für die neue Page aus der alten herauslesen muss, eine neue URL daraus formen muss und danach einen neuen Parse-Request ausgebe.

Nach 'Page 750' bekomme ich folgende Fehlermeldung:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.createChunk(DeferredDocumentImpl.java:1921)
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.ensureCapacity(DeferredDocumentImpl.java:1828)
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.createNode(DeferredDocumentImpl.java:1840)
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.createDeferredTextNode(DeferredDocumentImpl.java:534)
at com.sun.org.apache.xerces.internal.parsers.AbstractDOMParser.characters(AbstractDOMParser.java:1189)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:464)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)

...
...
etc...

Ich habe die Meldung mal gegoogelt --> Link

Wie viel Memory hat den mein Parser genau benötigt?
Wie kann ich nun sowas in Eclipse eingeben um den Memorybuffer vollständig auszuschöpfen?

java -Xmx2048m [whatever you'd have written before]

 

[Marco13]

Schau mal unter "Run Configurations", da gibt es ein Tab mit einem Eingabefeld für die "VM Parameters" (oder Aguments?) wo man das
-Xmx1000m
reinschreiben kann.

 

[doi_project]

Schau mal unter "Run Configurations", da gibt es ein Tab mit einem Eingabefeld für die "VM Parameters" (oder Aguments?) wo man das
-Xmx1000m
reinschreiben kann.

Danke für den Vorschlag!
Ich hab's mal auf '-Xmx3000m' probiert mit meinem 4GB RAM MacBook Air. Hat aber nicht geholfen. Programm ist and der GLEICHEN Stelle abgestürzt.

 

[Marco13]

Hui, ist das ein 64bit Java? Bei 32bit ist eigentlich bei ca. 1200m Schluss...

Ggf. mal einen Profiler laufen lassen - im JDK/bin Ordner sollte schon eine "jVisualVM.exe" rumliegen, mit der sollte man analysieren können, wo der Speicher flöten geht...

 

[doi_project]

Hui, ist das ein 64bit Java? Bei 32bit ist eigentlich bei ca. 1200m Schluss...

Ggf. mal einen Profiler laufen lassen - im JDK/bin Ordner sollte schon eine "jVisualVM.exe" rumliegen, mit der sollte man analysieren können, wo der Speicher flöten geht...

Ich benutz einen MacBook Air - da gibt es glaube ich kein 'jVisualVM.exe' :noe:

 

[Marco13]

Hm... vielleicht kann da ein Mac-User genaueres dazu sagen, sorry :bahnhof:

 

[langhaar!]

Ich arbeite an einem SAX Parser

Laut deiner Fehlermeldung ist es ein DOM-Parser.
Vielleicht würde ein SAX
Parser helfen?
Vergleich: DOM vs. SAX

 

[Kevin94]

Im übrigen hängt der maximal verfügbare Speicherplatz sehr stark vom System ab. Bei mir sind es etwa 1600m (bei 4GB RAM und 32bit JAVA). Wenn man aber zuviel an gibt sollte JAVA gar nicht starten (zumindes bei Windoof). Kann sein das der Parameter bei einem Mac einfach ignoriert wird, wenn er zu hoch ist und wie soll man 3GB für den Heap Space haben, wenn auch noch der Stack und das OS RAM braucht?

 

[doi_project]

Laut deiner Fehlermeldung ist es ein DOM-Parser.
Vielleicht würde ein SAX
Parser helfen?
Vergleich: DOM vs. SAX

Das habe ich jetzt auch von einem Arbeitskollegen gehört.
Aber ich verstehe nicht, was ich falsch gemacht habe...
Siehst du ein Problem in einem Code (siehe Anhang - Java-Klasse FullDatabaseParser) ??

 

[winSharp93]

Hallo doi_project,

ich würde mal versuchen, von dem rekursiven Ansatz wegzukommen.
Probiere testweise mal eine Schleife für die Pages.

So kannst du sicherlich schon mal einigen Overhead einsparen.

Ich weiß nicht genau, wie das der Garbage Collector (bzw. die OSX-Version) macht - aber evtl. werden die Objekte einer Methode erst freigegeben, wenn die Methode komplett ausgeführt wurde. Dies wäre aber ja bei Rekursion nicht der Fall, sodass du die ganzen Parser der vorherigen Seiten noch komplett im Speicher hast.

 

[mfernau]

Bei Rekursionen wird jeder Methodenaufruf (und damit dessen Variablen) auf den Stack gelegt und nach Abschluss von oben herab wieder aufgelöst. Rekursionen sind natürlich eine tolle, elegante und oft auch kürze (in LOC gesehen) Darstellungsweise als die Iterativen Ansätze. Aber soweit ich weiss langsamer und natürlich speicherintensiver - eben wegen diesem Stack-Prozedere.

 

[Marco13]

Der Stack sollte damit eigentlich nichts zu tun haben (enthält nur lokale variablen, hat nichts mit dem GC zu tun, und würde einen StackOverflowError und keinen OOME werfen). Ggf. morgen mal den Code anschauen...

 

[doi_project]

Hallo doi_project,

ich würde mal versuchen, von dem rekursiven Ansatz wegzukommen.
Probiere testweise mal eine Schleife für die Pages.

Ich habe doch keine Rekursion hier verwendet??

Ich bin lediglich nach diesem Tutorial vorgegangen.

 

[winSharp93]

Ich habe doch keine Rekursion hier verwendet??

Doch - zwar rufst du nicht rekursiv eine Methoden des gleichen Objektes auf, dafür aber immer die gleiche Methode eines neuen Objektes.

Hier mal die relevanten Teile des Codes:

public class FullDatabaseParser {
  //...
  public void getAllRequiredValues(String url) {
    //...
      FullDatabaseParser parser = new FullDatabaseParser(); //Zeile 168
      //...
      parser.getAllRequiredValues(newPage); //Da haben wir sie, die Rekursion ;-)
    //...
  }

 

[doi_project]

Doch - zwar rufst du nicht rekursiv eine Methoden des gleichen Objektes auf, dafür aber immer die gleiche Methode eines neuen Objektes.

Hier mal die relevanten Teile des Codes:

public class FullDatabaseParser {
  //...
  public void getAllRequiredValues(String url) {
    //...
      FullDatabaseParser parser = new FullDatabaseParser(); //Zeile 168
      //...
      parser.getAllRequiredValues(newPage); //Da haben wir sie, die Rekursion ;-)
    //...
  }

Achso - das ist auch Rekursion??? Aber ich erstell ja jedes Mal ein neues Objekt - hmmm...
Kann mir nicht vorstellen, wie ich das umgehen soll ??

 

[fastjack]

Du machst ständig neue Parser auf, die alten bleiben bestehen. Whl. bleiben alte Seiten dann auch noch als Objektstrukturen im Speicher und irgendwann ist halt Schicht in Schacht...