# JConsole - Auswirkung auf Performance



## janw (6. Juni 2007)

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 (6. Juni 2007)

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 (6. Juni 2007)

ok, das klingt gut
danke


----------



## Thomas Darimont (6. Juni 2007)

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 (6. Juni 2007)

Thomas Darimont hat gesagt.:


> 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 (6. Juni 2007)

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 (6. Juni 2007)

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...



Thomas Darimont hat gesagt.:


> 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


----------

