OutOfmemory Exception bei sehr großer Liste (Tomcat Webservice)

[RBS2002]

Hi,

ich habe folgendes Problem mit folgender Ausgangssituation:

* Liste mit ca. 40000 Datenobjekten wird von IBATIS zurückgegeben - bis dahin durch fetch Operation alles fehlerfrei
* Diese Datenobjekte enthalten jeweils 1 Liste mit 2 Einträgen die in separate Objekte gekapselt werden müssen ==> es entsteht eine Liste mit 80000 Datenobjekten (je 7 Objekte mit seperaten Namen von der internen Liste vom neuen Typ)

Die Liste mit den 80000 Datenobjekten wird danach sortiert (Anforderung an den Webservice). Soweit so gut - nur bekomme ich bei der Generierung der 2.Liste eine OutofMemory Exception. Versuche schon, nachdem das alte Objekt von der ersten Liste nicht mehr gebraucht wird, dieses zu löschen und den gc anzuwerfen bzw. diesen anwerfen zu wollen (java entscheidet ja bei system.gc() glaube ich selber). Habe jetzt schon an diversen Parametern für die java Speicherverwaltung gespielt und es soweit hinbekommen das er 100 Einträge verarbeiten kann - nur bei 40000 ist das natürlich sehr wenig.
Ich bin noch auf der Suche nach einer Lösung - aber wie würdet ihr in dem Fall vorgehen bzw. was sollte man unbedingt vermeiden (Schleifen etc. kann ich ja nicht vermeiden)

Vielen Dank im Voraus und mfG
RBS2002

 

[maki]

Hi,

wäre es möglich dass du nicht alles auf einmal lädst? (pagination/paging)

Gibt es eine PaginatedList in deiner iBatis Version?

 

[Kevin94]

Was sind das für Objekte, dass bei mehr als 100 davon der Speicher voll ist? Wenn man mal davon ausgeht, dass 1000MB RAM für den Server mindestens drin sind, müsste so ein Objekt, mit abhängigen Objekten, fast 10MB haben. Oder kriegt der Webserver viel weniger RAM als ich jetzt veranschlagt hab?
Aber selbst mit der Standart Einstellung von 128MB Heap müsste so ein Objekt noch fast 1MB haben, um das zu erklären.

GC manuell anwerfen bringt afaik garnichts, zum einen ist es nur eine Aufforderung, kein Zwang, zum anderen wird bevor ein OutOfMemoryError geworfen wird, der GC sowieso angeworfen.
Wenn die erste Liste ausserdem so klein ist, dass die 40.000 Objekte bequem in den Speicher passen, bei den generierten Objekten aber nur 100, ist das Löschen der alten Objekte nur ein Tropfen auf den heißen Stein.

 

[RBS2002]

die Objekte an sich sind nicht sehr groß, es sind im Prinzip nur Strings (und glaube 2,3 Integer) - also nichts was dieses wirklich erklären würde, zu mindestens wird der Speicher, selbst wenn 1000MB laut SoapUI zur Verfügung stehen, ordentlich zugeballert - bis zum Ibatis Teil ist es durch ein fetching von 500 schon problemlos, ohne das gibt es schon dort Probleme. Wenn ich morgen wieder an den Code komme kann ich den ja mal posten, vielleicht mache ich das auch zu kompliziert und man kann noch etwas optimieren (das sowieso, zu mindestens im Code Stil, ist bisher mehr Trial&Error bis es läuft). Habe auch schon an ein paar Parametern rumgespielt um Java für den Heap mehr Speicher zur Verfügung zu stellen, aber bisher noch nicht die richtigen Konfigurationen gefunden - konnte es bisher nur von 30 Sekunden auf 6 Minuten steigern - bis es abbricht. Mein Rechner hat 8GB Ram und Windows 7 - vielleicht hat ja jemand da Vorschläge.

Ansonsten hört sich diese PaginatedList gut an, kenne ich bisher noch gar nicht und werde ich morgen mal ausprobieren. Wenn der Garbage das aktuelle Datenbankobjekt gleich aus dem Speicher entfernen kann wäre das ja schonmal eine gute Lösung, so wird es sicher trotz dem remove am Ende der Schleife sicher im Speicher behalten und irgendwann entfernt.

Ansonsten vielen Dank erstmal

 

[RBS2002]

Das Problem hatte wahrscheinlich folgenden Ursprung:

- Anscheined verballert SOAPUI beim zeichnen des Ausgabefensters so viel Speicher das er dadurch eine OutOfMemory Exception
- Bei der Überführung von den Java Listen zu den SOAP Arrays wurde auch extrem bzw. ungewöhnlich viel Speicher verbraten
- SOAPUI scheint momentan einen Bug zu haben das, wenn in einer Ausgabezeile zu viel Text steht (bzw. zu lange), das Programm komplett abstürzt (mit nightlyBuild und Release Version). So konnte er eine XML im Pretty Format ohne Probleme ausgeben, als BASE64 String oder im RAW Format kam es zum Absturz wenn das SOAPUI Fenster aktiv war oder kurz danach der GC angeworfen wurde

Irgendwie wurde das Problem damit behoben. Vielleicht bringt JSON etc. noch ein paar Einsparungen in Sachen Performance - ansonsten läuft es erstmal soweit. Ein Paging gab es direkt nicht (zu mindestens nicht beim SqlMapClientTemplate, die dortige Skip und Max Funktionalität hat das eher noch verstärkt bzw. aus 5 Minuten sind ca. 65 geworden)

Ansonsten vielen Dank für eure Hilfe,
mfG RBS2002