Does changing JVM arguments on WAS make the application (DNG,QM) performance improve ?
Hi Team,
We have distributed topology of CLM 501 and recently we migrated the application server from Tomcat to WAS 8.5. After migration we are getting lot of complaints from project team about the application performance - system not seem to be responding.
[ especially from DNG while creating baseline for artifacts ]
Below are the default configuration we have set during the configuration.
Generic JVM arguments
-Xmx4g -Xms4g -Xmn512m
-Xgcpolicy:gencon -Xcompressedrefs
-Xgc:preferredHeapBase=0x100000000
-XX:MaxDirectMemorySize=1G
our server has got 8 GB of physical memory and the team is facing lot of issues (application not responding) at that time the available free memory showing as 9% Let me know if modifying any JVM arguments will make some difference.
Any suggestions would be of great help.
|
2 answers
|
Below is what we had as Tomcat JVM settings
-Dcatalina.home=C:\PROGRA~1\IBM\JazzTeamServer501\server\tomcat
-Dcatalina.base=C:\PROGRA~1\IBM\JazzTeamServer501\server\tomcat
-Djava.endorsed.dirs=C:\PROGRA~1\IBM\JazzTeamServer501\server\tomcat\endorsed
-Djava.io.tmpdir=C:\PROGRA~1\IBM\JazzTeamServer501\server\tomcat\temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=C:\PROGRA~1\IBM\JazzTeamServer501\server\tomcat\conf\logging.properties
-DJAZZ_HOME=file:///C:/PROGRA~1/IBM/JazzTeamServer501/server/conf
-Djava.awt.headless=true
-Dorg.eclipse.emf.ecore.plugin.EcorePlugin.doNotLoadResourcesPlugin=true
-Dcom.ibm.team.repository.tempDir=C:/PROGRA~1/IBM/JazzTeamServer501/server\tomcat\temp
-Djazz.connector.sslProtocol=SSL_TLS
-Djazz.connector.algorithm=IbmX509
-Dlog4j.configuration=filC:///C:/PROGRA~1/IBM/JazzTeamServer501/server/conf/startup_log4j.propertiess
-Xgcpolicy:gencon
-Xgc:preferredHeapBase=0x100000000
-XX:MaxDirectMemorySize=1G
-Xmx2G
-Xms2G
-Xmn512M
-DSQLSERVER_JDBC_DRIVER_FILE=C:\PROGRA~1\IBM\JazzTeamServer501\server\sqlserver\sqljdbc4.jar
Even in this case it used to throw out of memory error and the workaround was to get the server bounced.
Hence based on the recommendation from IBM we have migrated to WAS now it look even worse than before. Especially when some of the project team in DNG when they create baselines it will hung and become inaccessible.
|
If you were using Tomcat, you also would have had a <app install>/tomcat/conf/server.xml file where you specified threads, e.g.
maxThreads="150" minSpareThreads="25" Websphere usually defaults to 50 threads, where we advise increasing this to 200. There should be some fairly pertinent errors in the Websphere logs regarding threads. From the Interactive Installation Guide, you can see how to verify your current level and increase if it is less than 200: To improve performance of the operating procedures, change the WebContainer thread pool size settings:
Kind regards, Paul Comments The webcontainer thread pool size increase to 200 for both minimum and maximum was a part of a configuration changes when switching over to WAS from tomcat and has been already entered. I would recommend that you follow:
-Xmx2G
-Xms2G
-Xmn512M
in Tomcat, but if so you've doubled your heap size (a good thing), but you may have opened the pipe for other issues. If this is your DNG server then -Xmx4G -Xms4G -Xmn1G is probably more appropriate, if not 1500M. Are there messages in the logs? Connections to the database (JDBC pool/mediator pool)? |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
What's the JVM arguments for the original Tomcat deployment? Any changes except for switching from Tomcat to WebSphere?
No other changes have been made except the switch over