MemoryLeak bei Tomcat4/JSP/MYSQL-Projekt

[fredy]

Hallo!

Wir haben ein JSP-Projekt mit den folgenden
Komponenten entwickelt: JAVA (JSP), Tomcat4, JDK 1.3, Linux RedHead

Nachdem das ganze ca. 1 Woche lang gelaufen ist, ist der
RAM (1 GB!!) voll.
Wo könnte das Problem liegen ?
Gibt es bekannte Probleme und eventuelle bekannte Problemlösungen
dieser Art in Hinblick auf die oben angeführten Komponenten ?

Kann man in JSP programmiertechnisch so ein Problem hervorrufen ?

• Es gibt zwar den GC, was passiert aber, wenn man eine Connection
    nicht schließt ?

Wir setzen den MM-Treiber für mySQL ein. Könnte dieser
der Übeltäter sein ?
Wenn ja, welche alternativen JDBC-mySQL-Treiber gibt es ?

Macht es Sinn, auf JDK 1.4 upzudaten ?

Was ist nicht möchte ist tagelang herumprobieren, bis
vielleicht das Problem gelöst ist ...

Danke für Eure Hilfe
Manfred

[Reiner]

Hallo!

Wir haben ein JSP-Projekt mit den folgenden
Komponenten entwickelt: JAVA (JSP), Tomcat4, JDK 1.3, Linux RedHead

Nachdem das ganze ca. 1 Woche lang gelaufen ist, ist der
RAM (1 GB!!) voll.
Wo könnte das Problem liegen ?
Gibt es bekannte Probleme und eventuelle bekannte Problemlösungen
dieser Art in Hinblick auf die oben angeführten Komponenten ?

das liegt sehr wahrscheinlich am Tomcat. Der geht mit Speicher sehr ineffizient um.
Abhilfe dürfte wohl nur sein, ihn alle paar Tage (vielleicht per Cron) neu zu starten.

Gruß
Reiner

[Martin Jung]

Hi,

Nachdem das ganze ca. 1 Woche lang gelaufen ist, ist der
RAM (1 GB!!) voll.
Wo könnte das Problem liegen ?
Gibt es bekannte Probleme und eventuelle bekannte Problemlösungen
dieser Art in Hinblick auf die oben angeführten Komponenten ?

Kann man in JSP programmiertechnisch so ein Problem hervorrufen ?

• Es gibt zwar den GC, was passiert aber, wenn man eine Connection
    nicht schließt ?

Habt Ihr Testklassen bzw. ein Testsystem, die Euer "ein Wochen Problem" simulieren?
wenn ja:

• verwendet einen anderen Treiber (müsst Ihr schon selbst suchen) und prüft mit Eurem Testsystem, ob das Problem verschwindet. Das automatische Connection closing wird durch den Treiber gemanagt. Wenn er unsauber implementiert ist (z.B. nicht alle internen Referenzen auf die Connections freigibt), kann der GC auch nichts entsorgen.
• "closed" die Connections explizit und schaut, ob das Problem verschwindet. Eplizites Schließen verringert übrigens die Wahrscheinlichkeit, dass ein solches Problem mit irgendeinem JDBC-Treiber auftritt.
• überlegt, ob es generell nicht sinnvoller ist, über die Einführung einer Connection-Pooling Komponenete nachzudenken

noch eine Anmerkung:
Es gibt sher viele Produktivsystem mit Eurer Hardwarearchitektur, die im Dauereinsatz ohne jegliches Speicherproblem laufen.

Viele Grüße,
Martin