CODEWITHSUNDEEP
javaperformancetomcat
Shivanand
Shivanand

Reputation: 11

Weblogic to tomcat migration performance issue

We successfully migrated our web applications from Weblogic to tomcat 7. The web application is built using.

  1. Spring
  2. Jsp
  3. Uses the weblogic Datasources

When we migrated to Tomcat we started using DBCP. But thinking to change to Tomcat JDBC Connection pooling. Please suggest would this be helpful.

The application has to perform some heavy transactions on the server side.

But the tomcat fails to deliver the performance and stability which we get in weblogic.

There are too many GC thread running on tomcat and this makes the application to hang. Almost 2/7 of the total time is spent on GC.

Here is the JVM initialization string

JAVA_OPTS="$JAVA_OPTS -server -Xms120G -Xmx120G -Xmn60G -XX:PermSize=512m -XX:MaxPermSize=512m -XX:MaxNewSize=40G -XX:NewSize=40G -Xloggc:$CATALINA_HOME/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+DisableExplicitGC -XX:+CMSClassUnloadingEnabled -XX:+UseLargePages -XX:LargePageSizeInBytes=1200m"

Please help me to tune the tomcat for better performance and stability.

Upvotes: 1

Views: 1183

Answers (1)

Michael
Michael

Reputation: 7428

A few questions immediately jump out:

  • What profiling and analysis have you done to lead you to believe that you need 120 GiB of heap space?
  • Are you aware of the GC implications of a very large heap?
  • Do you have enough physical memory for the entire Java process, not just the heap?
  • Why are you explicitly setting the max size of the young generation to 60 GiB and new to 40 GiB?

If we take a look at the options you've specified:

-server 
-Xms120G 
-Xmx120G 
-Xmn60G 
-XX:PermSize=512m 
-XX:MaxPermSize=512m 
-XX:MaxNewSize=40G 
-XX:NewSize=40G 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+UseConcMarkSweepGC 
-XX:+CMSIncrementalMode 
-XX:+DisableExplicitGC 
-XX:+CMSClassUnloadingEnabled 
-XX:+UseLargePages 
-XX:LargePageSizeInBytes=1200m

It reads like a list by someone who's read one too many 'Java performance' blogs. If you can't explain what each option does and why you've added it as an argument, remove the option.

Typically, the JVM handles itself well - often making better decisions about things like how much eden space it needs etc. If you're going to set much more than the heap and perm gen sizes (and even then...) you really need to know what you're doing...

Unfortunately, there are no magic settings and that's especially true if your application is particularly heavy.

Start from a set of realistic base settings, use tools like JVisualVM, JMeter, MAT et al. to look at an overview of the behaviour of your application. Record metrics on performance, heap usage, concurrent threads, throughput (peak and average), time spent doing garbage collection and the stability of your app. Each time you make a change, record the same metrics and record the results. Eventually, you'll have an application tuned properly and you'll understand whether each setting is actually having a positive effect on performance.

Upvotes: 3

Related Questions