BufferedReader#readLine und OutOfMemoryException
Chris Seidel
wenn ich große Textdateien (> 10 GB) einlese, bekomme ich bei
BufferedReader#readLine eine OutOfMemoryException:
Das passiert ca. bei Zeile 1.200.000.
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)
at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)
at java.lang.AbstractStringBuilder.append(Unknown Source)
at java.lang.StringBuffer.append(Unknown Source)
at java.io.BufferedReader.readLine(Unknown Source)
at java.io.BufferedReader.readLine(Unknown Source)
jhat/VisualVM sagen mir, dass sich der Speicher zu 94 % als char[]
manifestiert.
M.E. speichere ich da nichts zwischen, sondern schreibe das was kommt
gefiltert in einen neuen Writer der in eine Datei schreibt. Die wird zu
etwa 2 GB vollgeschrieben, bis dann die OOME kommt. Dateisystem ist NTFS
unter W2K.
Ich habe nur den Heapdump, der hilft aber nicht wirklich weiter, oder? Die
Infos, dass es char[] ist, sagt mir ja nicht wirklich, wo es hängt.
Zum Debuggen fehlt mir im Moment leider eine solch große Datei.
Was kann ich tun? Ggf. bekanntes Problem?
Danke
Bernd Hohmann
> M.E. speichere ich da nichts zwischen, sondern schreibe das was kommt
> gefiltert in einen neuen Writer der in eine Datei schreibt. Die wird zu
> etwa 2 GB vollgeschrieben, bis dann die OOME kommt. Dateisystem ist NTFS
> unter W2K.
Müsste man den Source sehen. Verdachtsweise kannst Du Dir ja mal via
System.out.println(" free: "+Runtime.getRuntime().freeMemory());
System.out.println(" total: "+Runtime.getRuntime().totalMemory());
System.out.println(" max: "+Runtime.getRuntime().maxMemory());
in der Schleife alle 100 Durchgänge anzeigen lassen, wie es um den
Speicher bestellt ist.
Irgendwo wird wohl eine Referenz nicht korrekt abgeworfen und der GC
zugeführt oder aus irgendeinem Grund liegt da ein String herum, dessen
internes Chararray shared bleibt und immer weiter wächst.
Bernd
--
Visit http://www.nixwill.de and http://www.spammichvoll.de
jean....@nixwill.de & bernado....@spammichvoll.de
Bernd Eckenfels
> Ich habe nur den Heapdump, der hilft aber nicht wirklich weiter, oder? Die
Wenn du den Eclipse MAT drauf los lï¿œsst sagt der dir wo deine char Arrays
hï¿œngen. Kandidaten sind serialisierung (reset() verwenden) oder Collections.
Reader/Writer machen jedenfalls keine Probleme - es sei denn du hast
ï¿œberlange Zeilen...
Gruss
Bernd
Rudolf Ziegaus
> Chris Seidel wrote:
>
>> M.E. speichere ich da nichts zwischen, sondern schreibe das was kommt
>> gefiltert in einen neuen Writer der in eine Datei schreibt. Die wird zu
>> etwa 2 GB vollgeschrieben, bis dann die OOME kommt. Dateisystem ist NTFS
>> unter W2K.
>
> M�sste man den Source sehen. Verdachtsweise kannst Du Dir ja mal via
>
> System.out.println(" free: "+Runtime.getRuntime().freeMemory());
> System.out.println(" total: "+Runtime.getRuntime().totalMemory());
> System.out.println(" max: "+Runtime.getRuntime().maxMemory());
>
> in der Schleife alle 100 Durchg�nge anzeigen lassen, wie es um den
> Speicher bestellt ist.
>
> Irgendwo wird wohl eine Referenz nicht korrekt abgeworfen und der GC
> zugef�hrt oder aus irgendeinem Grund liegt da ein String herum, dessen
> internes Chararray shared bleibt und immer weiter w�chst.
>
> Bernd
Vielleicht kann der GC die Strings ja einfach nicht schnell genug
entsorgen?
Aber das w�rde man dann ja wahrscheinlich mit der von dir vorgeschlagenen
Ausgabe sehen, da m�sste ja der verf�gbare Speicher ab und zu mal wieder
etwas raufgehen.
Man k�nnte auch noch �berpr�fen, ob der GC �berhaupt anl�uft, da gibt's
doch einen Kommandzeilenparameter daf�r.
Rudi
Malte Schirmacher
> Vielleicht kann der GC die Strings ja einfach nicht schnell genug
> entsorgen?
Nein.
> Man k�nnte auch noch �berpr�fen, ob der GC �berhaupt anl�uft, da gibt's
> doch einen Kommandzeilenparameter daf�r.
Bevor eine OOM kommt wird IMMER der GC �ber den Speicher laufen.
Heiner Kücker
> wenn ich große Textdateien (> 10 GB) einlese, bekomme ich bei
> BufferedReader#readLine eine OutOfMemoryException:
> Das passiert ca. bei Zeile 1.200.000.
>
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Unknown Source)
> at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)
> at java.lang.AbstractStringBuilder.append(Unknown Source)
> at java.lang.StringBuffer.append(Unknown Source)
> at java.io.BufferedReader.readLine(Unknown Source)
> at java.io.BufferedReader.readLine(Unknown Source)
>
> jhat/VisualVM sagen mir, dass sich der Speicher zu 94 % als char[]
> manifestiert.
>
> M.E. speichere ich da nichts zwischen, sondern schreibe das was kommt
> gefiltert in einen neuen Writer der in eine Datei schreibt. Die wird zu
> etwa 2 GB vollgeschrieben, bis dann die OOME kommt. Dateisystem ist NTFS
> unter W2K.
Die Zeile
> at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)
sagt aus, dass das Problem nicht beim Lesen aus dem darunter liegenden
Stream, sondern beim Aufbau einer Zeile auftritt.
Also könnte eine überlange Zeile das Problem sein.
Versuch doch mal eine der Read-Methoden
read()
read(char[], int, int)
Bei der zweiten read-Methode ( read(char[], int, int) ) kannst
Du das char-Array sogar wiederverwenden.
Es gibt eben keine Unterteilung in Zeilen,
ich weiss nicht, ob Du diese Funktionalität benötigst.
> Danke
Bitte
Heiner
www.heinerkuecker.de
Lothar Kimmeringer
> wenn ich gro�e Textdateien (> 10 GB) einlese, bekomme ich bei
> BufferedReader#readLine eine OutOfMemoryException:
> Das passiert ca. bei Zeile 1.200.000.
>
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Unknown Source)
> at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)
> at java.lang.AbstractStringBuilder.append(Unknown Source)
> at java.lang.StringBuffer.append(Unknown Source)
> at java.io.BufferedReader.readLine(Unknown Source)
> at java.io.BufferedReader.readLine(Unknown Source)
>
>
> jhat/VisualVM sagen mir, dass sich der Speicher zu 94 % als char[]
> manifestiert.
Wie lang ist denn diese einzelne Zeile? Wie hoch ist Xmx?
> M.E. speichere ich da nichts zwischen, sondern schreibe das was kommt
> gefiltert in einen neuen Writer der in eine Datei schreibt.
Willst Du bewusst Charsets aendern und die Newlines "normalisieren"?
Falls das mit den Newlines umbauen nicht erforderlich ist, lese
und schreibe char-Arrays direkt, indem du die entsprechenden
read- und write-Methoden verwendest.
> Die wird zu
> etwa 2 GB vollgeschrieben, bis dann die OOME kommt. Dateisystem ist NTFS
> unter W2K.
Wenn dein Xmx nicht bei > 1,5 GB liegt, kann es eigentlich nicht
daran liegen, dass die erzeugten Strings nicht vom GC abgeraeumt
werden koennen, sonst waere das schon viel frueher abgeraucht.
Wie lang ist denn die besagte Zeile?
> Ich habe nur den Heapdump, der hilft aber nicht wirklich weiter, oder? Die
> Infos, dass es char[] ist, sagt mir ja nicht wirklich, wo es h�ngt.
>
> Zum Debuggen fehlt mir im Moment leider eine solch gro�e Datei.
>
> Was kann ich tun? Ggf. bekanntes Problem?
Mach obiges Vorgehen, zur Not suchst du vor dem Schreiben im
gelesenen char-Array selbst nach Zeilenumbruechen und schreibst
statt dessen die gewuenschten heraus. Als Quickhack koennte man
das ja charweise vom BufferedReader lesen, etwa in folgender Art:
char read;
char newline = 0;
while ((read = br.read()) != -1){
switch(read){
case '\r':
case '\n':{
if (newline == 0 || newline == read){
out.write(NEWLINE); // char-Array, mit dem gewuenschten Newline
}
newline = read;
break;
}
default:{
newline = 0;
out.write(read);
break;
}
}
}
Direkt aus der Birne, kann im Detail daher falsch sein.
Falls das dann nicht mehr knallt, kann man das eventuell
schneller laufen lassen, wenn man blockweise char-Arrays
einliest und herausschreibt, wenn man aber BufferedReader
und -Writer benutzt, sollte das aber auch so zumindest
nicht zu sehr einbrechen.
Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
Lothar Kimmeringer
> Vielleicht kann der GC die Strings ja einfach nicht schnell genug
> entsorgen?
Es mag Arten eines GC-Laufs geben, die nebenlaeufig funktionieren,
aber wenn Not am Mann ist, haelt der GC die VM an und raeumt dann
exklusiv im Speicher herum. Bevor also ein OOME passiert, fand
mit Sicherheit ein solcher Lauf statt, der nicht genug Speicher
freigeben konnte.
Chris Seidel
wrote:
> Die Zeile
>
>> at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)
>
> sagt aus, dass das Problem nicht beim Lesen aus dem darunter liegenden
> Stream, sondern beim Aufbau einer Zeile auftritt.
>
> Also könnte eine überlange Zeile das Problem sein.
Das könnte es sein...
Denn ohne Xmx tritt die OOM bei Zeile 1.200.000 auf und mit 1500m bei
1.200.300...
300 Zeilen können da ja nicht 1500 - 64 MB ausmachen...
Hm, also ohne die Datei werd ich da wohl nicht weiterkommen, ich ich krieg
es mit meinen größten Dateien (100 MB) nicht nachvollzogen. Der Speicher
der VM rödelt dabei kontinuierlich irgendwo bei 40 MB.
Chris Seidel
<bern...@eckenfels.net> wrote:
> Chris Seidel <cse...@arcor.de> wrote:
>> Ich habe nur den Heapdump, der hilft aber nicht wirklich weiter, oder?
>> Die
>> Infos, dass es char[] ist, sagt mir ja nicht wirklich, wo es hängt.
>
> Wenn du den Eclipse MAT drauf los lässt sagt der dir wo deine char Arrays
> hängen. Kandidaten sind serialisierung (reset() verwenden) oder
> Collections.
Meine größte Datei zum Testen ist nur 100 MB.
Da bleibt der Prozess kontinuierlich bei ca. 40 MB.
35 MB hat er schon direkt nach dem Start, ohne dass die Datei schon
gelesen wird.
> Reader/Writer machen jedenfalls keine Probleme - es sei denn du hast
> überlange Zeilen...
Das ist es vermutlich...
Chris Seidel
<news2...@kimmeringer.de> wrote:
> Willst Du bewusst Charsets aendern und die Newlines "normalisieren"?
Das und mehr. Die Datei wird halt gefiltert (ähnlich einem select ... from
datei where...) und mit neuem Encoding und Zeilenumbruch und Format
rausgeschrieben.
> Mach obiges Vorgehen, zur Not suchst du vor dem Schreiben im
> gelesenen char-Array selbst nach Zeilenumbruechen und schreibst
> statt dessen die gewuenschten heraus. Als Quickhack koennte man
> das ja charweise vom BufferedReader lesen, etwa in folgender Art:
>
> char read;
> char newline = 0;
> while ((read = br.read()) != -1){
> switch(read){
> case '\r':
> case '\n':{
> if (newline == 0 || newline == read){
> out.write(NEWLINE); // char-Array, mit dem gewuenschten Newline
> }
> newline = read;
> break;
> }
> default:{
> newline = 0;
> out.write(read);
> break;
> }
> }
> }
Überleg ich mal, wenn die Datei nicht buggy ist, sondern wirklich so
monstergroße Zeilen hat.
Florian Weimer
> wenn ich gro�e Textdateien (> 10 GB) einlese, bekomme ich bei
> BufferedReader#readLine eine OutOfMemoryException:
> Das passiert ca. bei Zeile 1.200.000.
OutOfMemoryError ist �berladen, der Fehler tritt sowohl bei
Speichermangel auf, als auch bei der Allokation eines Arrays, dessen
Objektgr��e VM-Schranken �berschreitet (auch wenn gen�gend Speicher
vorhanden w�re).
> M.E. speichere ich da nichts zwischen, sondern schreibe das was kommt
> gefiltert in einen neuen Writer der in eine Datei schreibt. Die wird
> zu etwa 2 GB vollgeschrieben, bis dann die OOME kommt. Dateisystem
> ist NTFS unter W2K.
Wie lang sind die Zeilen bei Ein- und Ausgabe?
> Ich habe nur den Heapdump, der hilft aber nicht wirklich weiter, oder?
> Die Infos, dass es char[] ist, sagt mir ja nicht wirklich, wo es
> h�ngt.
Doch, es kl�rt zumindest, um welche Art von OutOfMemoryError es sich
handelt, und ob irgendwo �berlange Zeilen im Spiel sind.
Ansonsten w�rde ich es auch mal mit -client oder -Xint probieren...
Florian Weimer
> Vielleicht kann der GC die Strings ja einfach nicht schnell genug
> entsorgen?
Dann l�uft das Programm langsamer, bis der M�llsammler wieder
aufgeholt hat.
Bernd Hohmann
>> Vielleicht kann der GC die Strings ja einfach nicht schnell genug
>> entsorgen?
>
> Es mag Arten eines GC-Laufs geben, die nebenlaeufig funktionieren,
> aber wenn Not am Mann ist, haelt der GC die VM an und raeumt dann
> exklusiv im Speicher herum. Bevor also ein OOME passiert, fand
> mit Sicherheit ein solcher Lauf statt, der nicht genug Speicher
> freigeben konnte.
Dejure ja - die Praxis hat zumindest in der Vergangenheit gezeigt, dass
das nicht immer so läuft wie es die Doku beschreibt.
"Vergangenheit" heisst hier, dass ich es erst gar nicht darauf ankommen
lasse und in den Untiefen meines Frameworks immer ein Thread mitläuft,
der den Speicher überwacht und frühzeitig eine GC auslöst.
Denn eine GC auf grossem Speicher willst Du nicht haben wenn es eh schon
eng in Zeit und Raum ist :-)
Bernd Hohmann
>> Also könnte eine überlange Zeile das Problem sein.
>
> Das könnte es sein...
Jetzt wo Heiner es sagt: ich habe immer wieder mal Situationen wo statt
wohlgeformter Textzeilen plötzlich unerwarteter Müll kommt.
Du brauchst also die Orginaldatei zum testen, post mortem wirds nix.
Wanja Gayk
> Hallo,
>
> wenn ich große Textdateien (> 10 GB) einlese, bekomme ich bei
> BufferedReader#readLine eine OutOfMemoryException:
> Das passiert ca. bei Zeile 1.200.000.
>
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Unknown Source)
> at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)
> at java.lang.AbstractStringBuilder.append(Unknown Source)
> at java.lang.StringBuffer.append(Unknown Source)
> at java.io.BufferedReader.readLine(Unknown Source)
> at java.io.BufferedReader.readLine(Unknown Source)
>
>
> jhat/VisualVM sagen mir, dass sich der Speicher zu 94 % als char[]
> manifestiert.
>
> M.E. speichere ich da nichts zwischen, sondern schreibe das was kommt
> gefiltert in einen neuen Writer der in eine Datei schreibt.
Kann es sein, dass du zum Filtern Substrings nimmst und ggf. in eine Map
packst?
Substrings sind nichts anderes, als eine Kapsel mit Referenz auf das
ungekürzte original char[] mit start/endmarke.
Für die meisten Zwecke ist das super, aber in solchen Fällen schnell
tödlich.
Wenn du einen substring willst, der nicht am original char[] hängst, musst
du
String part = new String(orginal.substring(start,end));
machen.
Gruß,
-Wanja-
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Wanja Gayk
> Rudolf Ziegaus wrote:
>> Vielleicht kann der GC die Strings ja einfach nicht schnell genug
>> entsorgen?
>
> Nein.
Doch.
>> Man könnte auch noch überprüfen, ob der GC überhaupt anläuft, da gibt's
>> doch einen Kommandzeilenparameter dafür.
>
> Bevor eine OOM kommt wird IMMER der GC über den Speicher laufen.
Wenn die GC nicht mehr schnell genug aufräumen kann, sodass das Programm
fast nur noch im GC hängt, steigt er auch mit einer OOM aus, die folgende
Nachricht trägt:
"OutOfMemoryError: GC overhead limit exceeded"
Malte Schirmacher
> "OutOfMemoryError: GC overhead limit exceeded"
Chris Seidel
wrote:
> Kann es sein, dass du zum Filtern Substrings nimmst und ggf. in eine Map
> packst?
Ja aber nur pro Zeile und danach "schmeiß" ich alles wieder weg.
Wanja Gayk
Macht deine Aussage deswegen aber nicht richtiger.
Bernd Eckenfels
>>> Vielleicht kann der GC die Strings ja einfach nicht schnell genug
>>> entsorgen?
>> Nein.
> Doch.
Nein, auch nicht bei CMS - jedenfalls nicht wenn es nur ein Thread gibt.
Denn solange der letzte Not-FullGC laeuft kï¿œnnen ja keine neuen Objekte
angelegt werden. Wenn das nicht stï¿œndig vorkommt gibts keine OOM.
> Wenn die GC nicht mehr schnell genug aufrï¿œumen kann, sodass das Programm
> fast nur noch im GC hï¿œngt, steigt er auch mit einer OOM aus, die folgende
> Nachricht trï¿œgt:
> "OutOfMemoryError: GC overhead limit exceeded"
Nur beim CMS, das passiert aber nicht bei ner single threaded Anwendung.
(Und auch nicht wenn die Young Generation keine Survivor hat)
Gruss
Bernd
Florian Weimer
>> Bevor eine OOM kommt wird IMMER der GC �ber den Speicher laufen.
>
> Wenn die GC nicht mehr schnell genug aufr�umen kann, sodass das
> Programm fast nur noch im GC h�ngt, steigt er auch mit einer OOM aus,
> die folgende Nachricht tr�gt:
> "OutOfMemoryError: GC overhead limit exceeded"
Der Grund ist aber nicht, da� die GC zu langsam ist, sondern da� der
Heap nahezu vollst�ndig voll ist und da� die *Anwendung* keinen
Fortschritt mehr macht.
kohlerm
Wie Bernd schon empfohlen lass mal den Eclipse Memory Analyzer
drüberlaufen.
Es ist ziemlich ausgeschlossen, dass du mit einer single threaded
Anwendung einen OOM hinbekommst ohne das du irgendwie Speicher
festhälts( Objekte referenzierts)
Gruss,
Markus
On Feb 4, 11:04 am, Florian Weimer <f...@deneb.enyo.de> wrote:
> * Wanja Gayk:
>
> >> Bevor eine OOM kommt wird IMMER der GC über den Speicher laufen.
>
> > Wenn die GC nicht mehr schnell genug aufräumen kann, sodass das
> > Programm fast nur noch im GC hängt, steigt er auch mit einer OOM aus,
> > die folgende Nachricht trägt:
> > "OutOfMemoryError: GC overhead limit exceeded"
>
> Der Grund ist aber nicht, daß die GC zu langsam ist, sondern daß der
> Heap nahezu vollständig voll ist und daß die *Anwendung* keinen
> Fortschritt mehr macht.
Wanja Gayk
> Wanja Gayk <brixo...@yahoo.com> wrote:
>>>> Vielleicht kann der GC die Strings ja einfach nicht schnell genug
>>>> entsorgen?
>>> Nein.
>> Doch.
>
> Nein, auch nicht bei CMS - jedenfalls nicht wenn es nur ein Thread gibt.
> Denn solange der letzte Not-FullGC laeuft können ja keine neuen Objekte
> angelegt werden. Wenn das nicht ständig vorkommt gibts keine OOM.
Mir scheint, wir reden aneinander vorbei.
Wenn das Programm zu viel Zeit in der GC verbringt, gibt es die genannte
Exception.
Und das passiert genau dann wenn zu schnell zu viele Objekte erzeugt
werden.
Mit anderen Worten: der GC kann die Objekte nicht schnell genug weg räumen.
Könnte er sie schnell genug wegräumen, hätte er schließlich nicht
ausreichend Overhead um um einen Grund für jene Exception zu haben, oder?
>> Wenn die GC nicht mehr schnell genug aufräumen kann, sodass das Programm
>> fast nur noch im GC hängt, steigt er auch mit einer OOM aus, die
>> folgende
>> Nachricht trägt:
>> "OutOfMemoryError: GC overhead limit exceeded"
>
> Nur beim CMS, das passiert aber nicht bei ner single threaded Anwendung.
> (Und auch nicht wenn die Young Generation keine Survivor hat)
Ich denke man kann fast davon ausgehen, das mehr als ein Thread im Spiel
ist, selbst wenn der nicht wissentlich erzeugt wurde.
Aber ohne die Applikation zu kennen ist es ohnehin nur Stochern im Dunkeln.
Wanja Gayk
>>> Bevor eine OOM kommt wird IMMER der GC über den Speicher laufen.
>>
>> Wenn die GC nicht mehr schnell genug aufräumen kann, sodass das
>> Programm fast nur noch im GC hängt, steigt er auch mit einer OOM aus,
>> die folgende Nachricht trägt:
>> "OutOfMemoryError: GC overhead limit exceeded"
>
> Der Grund ist aber nicht, daß die GC zu langsam ist, sondern daß der
> Heap nahezu vollständig voll ist und daß die *Anwendung* keinen
> Fortschritt mehr macht.
Das Glas ist zu voll mit Wasser, wenn man da noch mehr Wasser nach gießt,
läuft es über.
..nein, im Glas ist zu wenig Luft übrig, deswegen läuft es über, wenn du
noch länger Wasser rein gießt.