Speicherprobleme bei grafischen BIRT-Reports

[RolfB]

Hallo zusammen,

Ich habe ein Problem mit der Report-Engine BIRT. Das Produkt frisst bei mir Speicher.

Zur Umgebung:

• Meine IDE ist Eclipse mit MyEclipse
• Report-Engine ist MyEclipse Reports, also eigentlich BIRT
• BIRT wird in einer Web-Application betrieben
• Als Application Server wird Tomat 6.0 verwendet
• Als Java-Umgebung die aktuellste Java6-JRE 1.6.0_22

Das Problem ist: wenn grafische Reports requestet werden, steigt der Speicherbedarf an.
Allerdings nicht direkt der Speicherbedarf in Java, sondern für das EXE.

MyEclipse Reports wird in den Projekten etwas anders integriert als bei Eclipse mit BIRT. Genauere Infos finden sich unter http://www.myeclipseide.com/documentation/reporting/reporting_birt/. Eclipse mit BIRT habe ich noch nicht selbst benutzt. Bei MyEclipse Reports werden jedenfalls in web.xml zwei untergeordnete Dienste für Viewer und Engine angemeldet.

Was geht:

• Normale Web-Request funktionieren
• Report-Requests ohne grafische Elemente, also nur mit Listen, gehen

Ich habe jetzt einige Tage an dem Problem geforscht und bereits einiges ausprobiert:

• Die Tomcat-Version ist nicht relevant. Das Produkt wird bei uns normalerweise mit 6.0.26 ausgeliefert. Ein installiertes aktuellstes 6.0.30 ändert nichts.
• Ein Upgrade der normalerweise verwendeten BIRT-Version von 2.5.1 auf 2.5.2 bringt nichts. Eine noch neuere Version könnte MyEclipse noch nicht.
• Hinweise darauf, den PermSpace zu vergrößern (was ich als keine wirkliche Lösung angesehen habe) bringt gar nichts.
• Ein Start von Command Line oder als Service ändert nichts
• Eine gefundene Lösung eines zusätzlichen Parameters für das JSP-Servlet hat nichts gebracht
• Eine gefundene ältere Lösung der Anpassung der BIRT Engine konnte für BIRT 2.5.2 weitestgehend validiert werden und der zusätzliche Vorschlag innerhalb von BIRT die JavaScript Engines nur synchronized aufzurufen hat auch nichts gebracht.
• Starten unter JBoss 6 klappt nicht wegen irgendwelcher undurchsichtiger Versionsprobleme bei Log4J (das versuche ich noch zum Laufen zu bringen)
• Starten unter JBoss 5.2 klappt nicht, wohl weil JBoss hier scheinbar unkorrekt Class-Loader verwendet.

Ich bin aktuell mit meinem Latein am Ende.
Die BIRT-Engine ist erheblich komplex und es kann meines Erachtens nicht durchdebugged werden, wo genau was passiert und was genau jetzt den bleibenden Speicherbedarf erzeugt.

Interessant sind noch folgende Punkte:

• Der Speicherbedarf den Java über sich aussagt wächst nicht.
• Wenn aus Eclipse heraus Tomcat gestartet wird, taucht das Problem nicht auf. Vielleicht achte ich aber auch nicht den richtigen Prozess. Tomcat6 gibt es dann jedenfalls nicht in der Prozess-Liste des Task-Managers.
• Ich hatte ein ähnliches Problem mit nicht gestoppten Threads. D.h. die haben nicht nur Platz in Java belegt, sondern auch am EXE selbst. Das Problem ist aber gelöst.

Ich bin für jeden Hinweis dankbar, wo das Problem liegen könnte oder was ich noch testen kann.

 

[Wildcard]

Das Problem ist: wenn grafische Reports requestet werden, steigt der Speicherbedarf an.
Allerdings nicht direkt der Speicherbedarf in Java, sondern für das EXE.

Welches exe denn?

 

[RolfB]

Tomcat6.exe

 

[maki]

Jetzt wäre der Moment gekommen, an dem du uns das Problem beschreibst:
Was meinst du mit "Speicherproblem"??

Wie ist denn der Speicher konfiguriert?

Ein Stacktrace wäre gut, Erlebnisberichte wie du per Trial& Error versucht hattest jeden anderen möglichen und unmöglichen AppServer auszuprobieren dagegen helfen nicht

Tomcat ist ein Webserver der in Java umgesetzt wurde und in der VM läuft, tomcat.exe ist nur der launcher, so wie eclipse.exe nur der launcher ist.

 

[RolfB]

Speicherproblem heisst: das Teil frisst Speicher.
Bei jedem Request sind am Anfang so 3MB weg, bzw. besitzt der Prozess Tomcat6.exe hinterher 3MB mehr allokierten Speicher. Nach so 1000 identischen Requests sind es nur noch 100KB je Request. Aber das summiert sich über die Tage dann doch zu stark.

Das mit dem Launcher ist mir grundsätzlich auch klar. Damit ist es aber ja nicht getan. Wie kann das überhaupt sein, dass dieser Launcher-Prozess Speicher frisst?

Ich habe gelernt: Der Prozess allokiert z.B. scheinbar unvermeidlich Speicher, wenn man einen Thread anlegt und startet. Das meiste davon gibt er auch wieder frei, wenn der Thread endet. Die Differenz scheint sich aber NICHT beliebig zu summieren. Ob DAS hier trotzdem die Ursache ist, kann ich beim besten Willen nicht sagen. Wenn ich Tomcat beende hat er nur zwei Threads offen. Das ist nicht schön, aber das werden auch nach 1000 Requests nicht mehr.

Da das Teil nicht abstürzt, gibt es auch keinen Stack Trace.

Die Speicherkonfiguration weiss ich leider selbst nicht so genau. Ich habe Tomcat (als Teil eines gefundenen Hinweises) folgende Parameter zusätzlich mitgegeben:
-XXermSize=256m
-XX:MaxPermSize=256m
Der Rest sind die eingebauten Parameter.

 

[maki]

Um wieviel Speicher insgesamt sprechen wir denn hier?
Dir ist klar dass Tomcat ein Server ist und von Haus aus ein paar hundert MiB an Heap brauchen wird.

Die Speicherkonfiguration weiss ich leider selbst nicht so genau...
Der Rest sind die eingebauten Parameter.

Du lässt ihn ja wohl hoffentlich nicht mit den defaultwerten laufen... so wie du es beschreibst ist es allerdings so.
Interessant wäre vor allem der Xmx wert, wenn der niedrig ist(defaultwert ist zu niedrig), würdest du den Effekt den du beschreibst sehen, allerdings ist das kein Problem sondern vollkommen normal.

Hört sich so an als ob es für dich "das erste mal" mit Tomcat ist?
Alles in allem solltest du dich mit der Tomcat Konfiguration auseinandersetzen, Doku gibt es genug, solltest die setenv.bat nutzen um deinen Speicher zu konfigurieren, würde Xms auf 512m setzen und Xmx auf 768m, die PermGenspace paramter hast du ja bereits.

Die tomcat.exe ist wohl ein nativer launcher der als Windowsservice gestartet wird, nutze den selber nicht, aber was du da siehst ist die JVM.

Alles in allem kein Problem... vor allem kein Speicherproblem

 

[RolfB]

Nach verschiedenen Versuchen und Testläufen hat sich folgendes herausgestellt:

• Das eigentliche Problem war, dass ich nicht wirklich wusste, wie Java Speicher benutzt. Das hätte ich vorher besser recherchieren oder ausprobieren sollen.
• Es gibt tatsächlich kein Speicherproblem. BIRT arbeitet offenbar völlig korrekt. Tomcat arbeitet offenbar völlig korrekt.
• Tomcat arbeitet als Windows Service mit Defaulteinstellung mit maximal 256m, was aber hier sogar reicht. Auch der Perm-Platz muss für unsere Anwendung wohl nicht zwingend erweitert werden. Zumindest schafft die Web-Application eine Nacht Dauerlast mit Defaultparametern ohne Probleme. Interessant für mich: als Service werden offenbar CATALINA_OPTS auch nicht ausgewertet.

Danke für die Hinweise zu meiner richtigen Erdung. Kaum testet man's richtig, schon sieht man, dass es von Anfang an ging.

 

[maki]

Probier mal VisualVM aus, da kannst du live ansehen was so im Speicher los ist und wie der GC arbeitet