Speicherbedarf und persistente Objekte

[Jens81]

Hallo zusammen,

ich habe folgendes Problem:

Ich lese Daten (1,5 mio) aus einer Datenbank aus (siehe auch http://www.java-forum.org/datenbank...hickt-groessere-datenmengen-unterbringen.html).

Um mir mehrfaches Laden von der Daten aus der DB zu sparen (wegen der langen Ladezeiten), speichere ich die geladenen Daten in einen Vector und diesen persistent ab:

OutputStream fos = new FileOutputStream("..."); 
ObjectOutputStream o = new ObjectOutputStream(fos); 
o.writeObject(...);

Das Lesen erfolgt analog:

InputStream fis = new FileInputStream("..."); 
ObjectInputStream o = new ObjectInputStream(fis); 
Vector werte_kompl = new Vector();
werte_kompl = (Vector) o.readObject();
fis.close();

Lade ich die Daten jedoch nun aus der Datei und nicht aus der DB, braucht die Anwendung einiges mehr an Arbeitsspeicher. Für ein Objekt wäre das noch ok, wenn ich aber mehrere Objekte laden möchte wird es eindeutig zu viel.
Wie kann ich das Problem abfangen? Gibt es bessere / andere / RAM-schonende Möglichkeiten zum speichern und lesen?

Danke und Gruß,
Jens

 

[musiKk]

Wie stellst Du das fest? Stürzt die JVM ab, wenn Du den Speicher nicht manuell per -Xmx erhöhst? Von welchen Zahlen reden wir (wieviel ist "einiges")?

 

[Jens81]

Den Speicher habe ich schon auf 1GB hochgesetzt.

Bisher habe ich noch kein Problem, da ich nur 1 oder 2 dieser Objekte laden muss. Auf längere Sicht werden das jedoch mehr werden, daher meine Frage ob es effizientere Möglichkeiten gibt.

Falls ich die Daten aus der DB lade benötigt die Anwendung 380 MB, lade ich sie aus den Objekt, dann verbraucht sie ca. 590MB. Die Angaben habe ich dem Windows TaskManager entnommen.

Ich dachte, dass es vielleicht auch eine Möglichkeit gibt, die Daten weniger komprimiert zu speichern (falls sie das überhaupt sind) und beim laden dann vielleicht weniger Speicher zu verbrauchen. Also quasi Plattenplatz gegen RAM tauschen.

 

[musiKk]

Also der Angabe des Betriebssystems würde ich nur wenig Glauben schenken. Die JVM hat ja ein Maximum an Speicher, den sie verbrauchen darf. Reicht der aktuelle Speicher nicht aus und ist dieses Maximum noch nicht erreicht, fordert sie beim Betriebssystem mehr an. Ich denke aber nicht, dass sie sofort den RAM wieder abgibt, wenn wieder weniger Speicher gebraucht wird -- falls das überhaupt mal geschieht. Das wäre jedenfalls nicht sonderlich effizient.

Du kannst ja mal mit VisualVM schauen, wieviel Speicher in der JVM tatsächlich verbraucht wird.

Davon abgesehen kenne ich mich mit reiner Serialisierung nicht so super aus, aber ich glaube nicht, dass die Daten standardmäßig komprimiert werden (das könnte man aber sehr einfach durch Dazwischenschalten eines ZipOutputStreams erreichen). So oder so sollte sich das aber nicht sehr auf den letztendlichen Speicherverbrauch der JVM auswirken. Die endgültigen Objekte sollten in beiden Fällen gleich viel Speicher benötigen und die Infrastruktur zur Deserialisierung braucht sicher keine 200m.

 

[velaluka]

Hallo Jens,
vielleicht solltes du mal einen Blick in diesen Cache werfen. Dort sind deine Probleme schon ziemlich professionel :rtfm: angegangen worden....
Oder eventuell mal nachforschen ob dir eine (eigene) Proxy Implementierung besser hilft.
Ciao velaluka