outOfMemoryError beim Einlesen einer Datei abfangen?

[gorgophol]

Hallo,

ich hab folgendes Problem. Ich musste beruflich eine Klasse schreiben, die folgendes tut:

1. Datei einlesen: die besteht aus x Zeilen mit jeweils einer Zuordnung --> Attribut=Wert
2. Speichern dieser Zuweisungen in einer Hashtable
3. werden zwei Strings übergeben (Attribut + Wert). Ist das Attribut vorhanden, soll der Wert zurückgeliefert werden, ansonsten die Hashtable und damit die Datei um diese Zuordnung erweitert werden.

Ok. soweit einfach. Ich les das ein und schreib die Daten entweder in einen Stringbuffer, den ich am Ende wieder in die Datei schreiben kann, oder nur in die Hashtable, die ich am Ende über ne Schleife in die DAtei schreiben kann.

Um das mit größeren Dateien testen zu können, hab ich mir eine Klasse geschrieben, die bis zu einem Maximalwert einfach Zuordnungen in einen Stringbuffer und den in eine Datei schreiben sollte. Da bekam ich den ersten outOfMemoryError bei knapp 215000 Zeilen. Das hab ich gelöst indem ich alle 200000 Zeilen, den Stringbuffer speicher und neu erzeuge. Also macht die Dateierzeugung keine probleme, außer man hätte keinen Plattenplatz mehr.

Logischerweise krieg ich ja aber die gleichen Speicherprobleme, wenn ich die Datei ja mit der ursprünglichen Klasse dann einlesen und weiter verarbeiten muss. Und da wüsste ich nicht, wie ich regelmäßig das alles zwischenspeichern sollte.

Hab schon mit Xms und Xmx versucht mehr Speicher zur Verfüguing zu stellen, bis meinem 1 GB Arbeitsspeicher, aber das hatte überhaupt keine Auswirkungen.

Hat noch jemand eine Idee?

 

[Beni]

Hm, soviel ich weiss, arbeiten Hashtable (und ganz sicher StringBuffer) mit Arrays. Wenn man aber z.B. einen 100MB-Array benötigt, muss dieser Speicher am Stück frei im RAM sein. Das passiert praktisch nie...
Nur mal aus Neugier: was passiert, wenn du anstelle einer Hashtable eine Datenstruktur wie die "java.util.TreeMap" (die ohne Arrays auskommt) verwendest?

Vielleicht würde sich für dieses Problem auch die Verwendung einer Datenbank lohnen. Dann must du dir keine Sorgen mehr wegen Speichermangel machen.

 

[gorgophol]

Das mit der anderen Speicherstruktur werd ich nächste Woche mal ausprobieren. Vielleicht wäre das ne Lösung. Direkt einfach irgendwie Speicher bereitstellen, der ja vorhanden wäre, kann man wohl nicht, oder?

Was die Datenbank angeht, die Zuordnungen, die in der Datei drinstehen, kommen ja letztendlich aus ner Datenbank. Mittels dieser DAtei will mein Kollege die jeweils korrekten Zuordnugnen in verschiedenen Systemen synchron halten. Naja. Das war jetzt schlecht erklärt, aber besser geht das auf die Schnelle net

Ich könnte vielleicht noch erwähnen, dass das eher ein Problem ist, weil ich ein bisschen Perfektionist bin in der Hinsicht und gerne hätte, dass meine Programme auch später noch verwendet werden können, wenn mal mehr Daten woanders anfallen sollten. Für den konkreten Fall werdens nie mehr als 10 - 20000 Zeilen...

Wobei meine Dateien immerhin schon 500.000.000 Zeilen aufweisen konnten, bei knapp 14 GB Größe

 

[Beni]

14 GB? Wow, damit arbeitest du in Bereichen die ich nur in der Theorie kenne...

Was ich aber sagen kann: du hast niemals genügend RAM für den Spass (zumindest nicht in naher Zukunft).
Darum möchte ich noch die Datenstruktur B-Tree einwerfen. Ein B-Tree ist so aufgebaut, dass man einen Teil auf der Festplatte einlagern kann. Nur der Teil mit dem man arbeitet, muss geladen werden.
Dein Programm hat doch hoffentlich keine Echtzeitanforderungen... ?

 

[Bleiglanz]

kannst du die datei nicht als property datei behandeln??

und falls nicht:

warum liest du alles in eine Hashtable ein, ist doch unsinn

iteriere durch die zeilen
wenn wert vorhanden für key => return diesen wert

wenn beim iterieren kein wert gefunden
mit append direkt ans File hinten anfügen

es gibt doch überhaupt keine veranlassung, den ges. dateiinhalt in den speicher einzulesen?

 

[gorgophol]

Also die 14 GB-Datei werd ich wohl auch nie benutzen. Das war mehr so zum Testen ob meine Dateierzeugungsprogramm irgendwelche weiteren Grenzen erreicht. Hat es nicht Außer die Grenzen der Festplatte eben ... Dass da der Speicher net reicht ist mir ja schon klar Aber mehr als 200000 Zeilen sollten halt drin sein, dachte ich. Aber ich guck mir auch B-Tree mal an. Danke Und nein, keine Echtzeitanforderung. Allein die Datei zu erstellen dauert gute 45 Minuten, bei der Größe Windows kann sie übrigens auch net mehr öffnen *g*

Also die Klasse, mit der ich das File einlese ist ne Erweiterung der Klasse Properties (oder Property?) die von Java ja mitkommt. Ich hab die erweitert, um eben genau auch Daten aus Files verarbeiten zu können, die man net als Property-Datei liefert.

Als Hashtable deshalb, weil ich dachte, dass ein Hashtable genau dafür da ist, schnell eine Zuordnung von Key und Wert überprüfen zu können. Ich will ja nicht immer durch die ganze Datei iterieren müssen. Grad wenn ich doch so riesige Dateien (zumindest theoretischt) verarbeiten können möchte. Zeilenweises Einlesen und Verarbeiten kam mir auch nie in den Sinn, weil ich gelernt hab, dass man für solche Fälle Stringbuffer und Hashtables benutzt

 

[Bleiglanz]

200000 Properties?

und du willst die immer wieder abfragen und nicht jedesmal durchiterieren?

(ich dachte du bräuchtest nur gelegentlich einen wert)

verwende lieber eine Datenbank und mach deinen key zum primärschlüssel einer einfachen tabelle, sollte noch relativ schnell sein

 

[gorgophol]

Nein. Es werden an Ende ca 20000 Zuordnugnen in der Datei stehen. In dem speziellen Fall.
Soweit kommt ja ne Hashtable noch super mit

Meine idee war eben, dass man das Prinzip irgendwie auch auf größere Datenmengen anwenden könnte. Weils eben so recht bequem ist und schneller, als immer durch die Datei zu iterieren.

Dass es beim reinen Iterieren keine Probleme geben sollte, ist mir klar, aber ich wollte das ja eben gerade verhindern Daher dieser Ansatz

 

[Bleiglanz]

Meine idee war eben, dass man das Prinzip irgendwie auch auf größere Datenmengen anwenden könnte.

ist IMHO eine schlechte Idee

warum riesige Mengen Hauptspeicher für eine Lookup-Tabelle verbraten, nur weil man ab und zu einen Wert braucht?

oder ist das ein performance-problem und du musst in jeder sekunde ein paar hundert keys nachschlagen (ist natürlich was anderes)

Hashtable und sowas ist normalerweise einfach für "kleinere" Datenbestände reserviert, ab 10000 Zeilen ist eine (embedded) Datenbank wahrscheinlich besser

 

[gorgophol]

ist IMHO eine schlechte Idee

warum riesige Mengen Hauptspeicher für eine Lookup-Tabelle verbraten, nur weil man ab und zu einen Wert braucht?

Das seh ich jetzt auhc ;-)

oder ist das ein performance-problem und du musst in jeder sekunde ein paar hundert keys nachschlagen (ist natürlich was anderes)

Naja. Früher oder später wirds ein Performanceproblem denk ich. Weil wenn man jetzt ganz bequem über eine Methode diesen Abgleich und die Erweiterung durchführen kann, ist es ja nur ne Frage der Zeit, bis jemand auf die Idee kommt, das ganze net mehr sporadisch per Hand aufzurufen, sondern automatisch über ne Schleife oder was auch immer. Ich will halt drauf vorbereitet sein und net dann erst merken, dass meine Klasse das net kann ...

Dass das per Hashtable wohl net geht ist relativ klar jetzt Aber das war halt die Anforderung. Man will da ja keine extra Datenbank für verwenden, sondern explizit das über ne Datei steuern.

 

[messi]

Man will da ja keine extra Datenbank für verwenden, sondern explizit das über ne Datei steuern.

Falls du es dir doch noch mit der Datenbank überlegst, schau dir mal die Portierung der Berkeley DB in pures Java an. Gibt es auch von Sleepycat.

 

[gorgophol]

Also die TreeMap scheitert noch vor der Hashtable.

Wie find ich den was über B-Tree? Hab ich noch nie von gehört

 

[messi]

Also die TreeMap scheitert noch vor der Hashtable.

Was heißt "scheitert"?

Wie find ich den was über B-Tree? Hab ich noch nie von gehört

B-Baum-Varianten werden von fast allen Dateisystemen und Datenbanken benutzt. Ich kenne jetzt keine konkrete Java-Klasse, die dir die Möglichkeit bietet, die Daten teilweise auf die Platte auszulagern. Aber letztlich wäre das dann wieder nichts anderes als eine Datenbank.
Schau dir einfach mal die Berkeley DB an. Das ist eine schnelle Schlüssel-Wert-DB. Kein SQL erforderlich. http://www.sleepycat.com/products/je.shtml

 

[gorgophol]

Scheitert heißt selber outOfMemoryError, nur etwas früher als bei Verwendung der Hashtable.

Also keine dramatischen Unterschiede. Vielleicht war die Klasse auch net mehr ganz identisch mit meiner Messung bei der Hashtable damals. Auf jeden Fall keine nennenswerte Verschiebung des Problems nach hinten.

Ich kann aber halt net einfach ne DB in die Firma schleppen und das ausprobieren Ich könnte höchstens was verwenden, was wir eh haben. Aber das war wie gesagt nicht gewollt ...
Zumindest hab ich jetzt die Grenzen von Java mal erreicht in der HInsicht

Trotzdem danke für eure Anregungen Vielleicht kann ich sie mal umsetzen, wenn die Aufgabenstellung entsprechend ist