JConsole - Auswirkung auf Performance

[janw]

Hallo,

mein Problem: Unser JBoss (4.03SP1 auf SuseLinux) verbraucht mit der Zeit immer mehr Speicher und läuft nach einer bestimmten Zeit zuverlässig auf einen "OutOfMemoryError: PermGen Space".
(Nein: keine Hot deployments und der Speicher ist auch schon erhöht, was aber das Problem nur verschiebt:
-Xmx512m -XX:MaxPermSize=200m)

Jetzt würde ich gerne den produktiven JBoss überwachen und mir Infos über den verbrauchten Speicher holen.
Da fällt mir die JConsole und Remote Monitoring ein (http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html), wurde auch schon in diesem Forum besprochen/vorgestellt.

Meine Frage: Hat es signifikante Auswirkungen auf die Performance, wenn ich für den JBoss den JMX Agent für Remote Monitoring aktiviere (http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#remote) ?
Hat jemand damit Erfahrungen?

Gruß
Jan

 

[Thomas Darimont]

Hallo,

meiner Erfahrung nach erzeugt ein Monitoring einer Java 5 JVM mit -Dcom.sun.management.jmxremote nur äußerst geringen Overhead den man eigentlich gar nicht merkt... IMHO ist das kein Problem. Bei Java 6 ist das Attachen ja jederzeit möglich ohne vorher das -Dcom... Flag anzugeben und auch da spricht man von absolut marginalem Overhead. Also IMHO spricht nichts dagegen Produktivsysteme mit der JConsole zu überwachen, dann aber mit "richtig" konfigurierter Authentifizierung und SSL-Verschlüsselung.

Gruß Tom

 

[janw]

ok, das klingt gut
danke

 

[Thomas Darimont]

Hallo,

"OutOfMemoryError: PermGen Space".
(Nein: keine Hot deployments und der Speicher ist auch schon erhöht, was aber das Problem nur verschiebt:
-Xmx512m -XX:MaxPermSize=200m)

Falls das ganze eine Webanwendung ist könnten die Schuldigen hier die JSP Seiten (oder was ihr auch immer als Präsentationsmechanismus verwendet) sein. Beim ersten Aufruf einer JSP wird diese in ein Servlet kompiliert. Zu jeder JSP gibts dann eine entsprechende Java Klasse. Ich hab schon oft erlebt, dass in großen Webprojekten durch eine Unmenge an JSPs so viele Klassen generiert wurden, dass es zur Laufzeit zu einem OOME: PermGen Space kam.

Gruß Tom

 

[janw]

Hallo,
Falls das ganze eine Webanwendung ist könnten die Schuldigen hier die JSP Seiten (oder was ihr auch immer als Präsentationsmechanismus verwendet) sein. Beim ersten Aufruf einer JSP wird diese in ein Servlet kompiliert. Zu jeder JSP gibts dann eine entsprechende Java Klasse. Ich hab schon oft erlebt, dass in großen Webprojekten durch eine Unmenge an JSPs so viele Klassen generiert wurden, dass es zur Laufzeit zu einem OOME: PermGen Space kam.
Gruß Tom

der OOME kommt nur im JBoss, der Tomcat ist auf einer eigenen Maschine - also an den JSPs liegts eher nicht. Wir verwenden EJBs (SLSBs 2.1 als Service-Fassade) und Hibernate...

Ein anderes Problem hab ich gerade beim connecten:
Zu unserem Testsystem kann ich mich mit der JConsole nicht connecten, aber programmatisch, da die Verbindung über einen proxy hergestellt werden muss.

Properties systemSettings = System.getProperties();
systemSettings.put("http.proxyHost", "...");
systemSettings.put("http.proxyPort", "...");
System.setProperties(systemSettings);

Kann ich das der JConsole auch irgendwie beibringen?

 

[Thomas Darimont]

Hallo,

der OOME kommt nur im JBoss, der Tomcat ist auf einer eigenen Maschine - also an den JSPs liegts eher nicht. Wir verwenden EJBs (SLSBs 2.1 als Service-Fassade) und Hibernate...

Okay, dann ist der OOME eher auf übermäößige Bytecodegenerierung zurückzuführen. Verwendet ihr cglib oder normale JDK Dynamic Proxies für Deferred-Loading Collections?

probiers doch mal mit:
jconsole -J-Dproxy.host=someProxyHost -J-Dproxy.port=12345

Ansonsten kannst du's ja auch mit MC4J versuchen:
http://mc4j.org/confluence/display/MC4J/Home?

Gruß Tom

 

[janw]

es lag doch nicht am Proxy. Mit der jconsole.exe vom jdk1.5.0_12 geht es nun
vorher hatte ich jdk1.5.0_6
whatever...

Hallo,
Okay, dann ist der OOME eher auf übermäößige Bytecodegenerierung zurückzuführen. Verwendet ihr cglib oder normale JDK Dynamic Proxies für Deferred-Loading Collections?

grübel...wir verwenden noch hibernate 3.1.3, und haben in der Hinsicht am Default-Wert nichts geändert. Standardmäßig wird dann glaubich cglib verwendet?!
Unser einziger Parameter in der Richtung:
<property name="hibernate.cglib.use_reflection_optimizer">false</property>

Die Architektur ist 3-schichtig, ohne lange Sessions/Transaktionen.

Gruß
Jan