Common Tomcat Memory Issues and How To Fix Them
Some of the most frequently reported Tomcat performance issues have to do with memory leaks, OutOfMemoryError messages, and JVM memory allocation. If you are experiencing any of these issues, read on - this article will help you understand exactly what's causing your performance issues, and how to correct them.
We'll also take a look at some of the things that make configuring Tomcat's memory settings a tedious task, and share some tools that allow you to quickly identify and repair memory issues, and enforce your configuration changes across multiple servers.
Say Goodbye To OutOfMemoryError Messages
OutOfMemoryError messages, or OOME's, are one of the most common problems that users experience with Tomcat. These messages can be caused by a wide variety of factors, and they severely affect application performance, so it's a good idea to do everything you can to prevent them before they occur. Here are the most common OOME-triggering situations, and steps to help you avoid them in the future.
Cause 1 - Memory Leaks
Memory leaks when relaunching applications, a commonly reported problem, are in fact usually traceable to flaws in the design of the web application, not Tomcat's codebase.
These applications most likely retain references to the web application class loader, preventing garbage collection processes from clearing classes from the Permanent Generation, or PermGen.
Because the PermGen has a finite size, reloading the flawed application just a handful of times can trigger an OutOfMemoryError, or OOME. Eliminating retained references to the web application class loader will allow Garbage Collection to function properly, preventing these errors.
Memory Leak Protection in Tomcat 7.0
Fortunately for developers, Tomcat 7, which will be released in summer of 2010, features a number of memory leak fixes and workarounds, and these have also been retroactively ported to Tomcat 6.0.x. Developers who are experiencing memory leak issues should consider upgrading to the latest version of Tomcat as soon as possible.
Cause 2 - Hardware Issues
An OOME message means one simple thing - you don't have enough memory to complete an operation. If your server is running with less than 128MB of RAM, the only true way to fix your issues will be to upgrade your system. Any other solution will only be a temporary patch, at best.
Cause 3 - Large Number of Frequently Recomplied JSPs
If your application includes a large number of JSPs that feature "frequently recompiled" objects such as dynamic headers, you should consider looking into the configuration of your JSP compiler. There are a number of steps that can be taken to prevent memory leaks from these pages, which may be chewing up your RAM.
Cause 4 - OS-Specific Threshold Limits
If you are running a *nix OS, your OOME may be caused by running out of file descriptors, which can occur if your threshold is set too low. You can change the threshold by using limit to increase the Max Processes per user limit to match your application's needs.
Another OS-specific factor that can cause OOME messages is a per-process thread limit. Your JVM is considered a single process, so if your OS has a low default threshold of threads per process, this may be causing your memory issues. The majority of OS's allow this threshold to be increased, so check your documentation.
Cause 5 - Insufficient Permanent Generation Size
Although your PermGen can be exhausted by improperly retained references to class loaders, it can also be filled up if your application simply uses a large number of JSP's and servlets. The default size is 64MB, but this can be increased by using the -XX:MaxPermSize= switch. Try doubling or quadrupling the size, and see if that eliminates the error messages.
Optimizing JVM Memory Allocation
Even if you're not getting any OOME messages, properly configuring your JVM's memory allocation is an essential part of getting the best performance out of Tomcat. JVM memory reallocation is an expensive process that can tie up power you want going to serving requests. Cutting down on the number of times it happens will give you a solid performance boost.
Step 1 - Eliminate Excessive Garbage Collection
Excessive garbage collection can stress your server's request-serving power. Starting the JVM with a higher maximum heap memory by using the -Xmx switch will decrease the frequency with which garbage collection occurs.
Additionally, if you don't mind lowering the total garbage collection throughput of your application, consider using the -Xincgc switch to enable incremental garbage collection.
Step 2 - Properly Configure Memory Reallocation
Utilizing these techniques along with the -Xms switch, which sets initial heap memory equal to the maximum heap memory, will eliminate any need for the JVM to resize or reallocate the heap memory, leaving more to be used by other memory-intensive processes.
Why Configuring Tomcat's Memory Settings Is So Tedious
Tuning Tomcat's memory usage to suit the needs of your applications offers big benefits to your site's performance, but it can also mean a lot of tedious work - log in via the terminal, open a configuration file, search through the XML, tweak a setting, restart the server, open up a monitoring client, find another error, tweak again, restart...
Add in a few clusters of servers running different applications, and you're looking at hours of repetitive testing and tweaking, multiple profiles to maintain, and the need to do it all over again on every Tomcat instance you're running if a new version of an application requires a change in settings.
It's no wonder that many Tomcat administrators grimly put up with frustrating memory usage errors or less-than-optimal configurations - manually testing and applying configurations is simply too much work for a busy administrator to handle.
Tcat Server Makes Enterprise Tomcat Administration A Reality
Don't let tedious configuration tasks prevent optimal performance! Mulesoft's Tcat Server makes Tomcat Administration a reality.
Running in front of your existing Tomcat infrastructure, Mulesoft's Tcat Server provides powerful monitoring, configuration, and administration tools to keep your Tomcat servers performing like never before. Every one of Tcat's powerful features is accessible from the same central web console - no more switching tools, looking up ports, or configuring SSH keys ever again.
How Tcat Server Saves You Time
To help you understand how Tcat Server saves you time, let's look at an example scenario. Let's say we are running three clusters of three Tomcat instances each, and each is running a different combination of applications, with different memory requirements. Lately, there have been a lot of memory errors on our servers, and it's having a real impact on our user experience. We have to make changes to our memory settings.
First, let's do things the old fashioned way - manually. Because we're running clustered instances, to find the proper memory settings, we'll have to test the cluster under load, log into one machine, change a setting, and then copy the configuration file to every other server in the cluster. Then, we'll simply manually issue a restart command to each server in the cluster, and test again. Oops! The setting's not quite right. Time to repeat the whole process. Too bad we have three clusters to configure; guess the third one will have to wait until tomorrow, along with all the other work we wanted to get done today.
Now, let's look at the same scenario using Tcat Server. Log in to Tcat's centralized web console and open up the Servers tab. Select the cluster you want to test first, and get instant, real-time, graphical data about your memory use. Navigate to the Server Profile you've created for this cluster, and make a change to the memory usage. With two clicks, publish the configuration to the entire cluster, and restart all your instances to see your changes take effect. Need to add a new worker to the cluster? No problem! Tcat Server lets you enforce an unlimited number of server profiles across your infrastructure, putting you in complete control of your network's performance.
Tcat Server is built on 100% Apache Tomcat, and is free to use in development and pre-production. Don't wait - get the administrative power you need. Download a free copy of Tcat Server today!
Comments on this post:
Submitted by jkim (not verified) on Tue, 2010-03-16 16:23. #
Apache Tomcat acts as an HTTP-based Web server, hosting Java-based Web applications. The Tomcat Web server can serve as a standalone Web application server, or as smaller component of a larger Web services framework.
The typical directory structure for a Tomcat web application deployment is as follows: tomcat/webapp, where 'webapp' is your web application.
Tomcat utilizes the Java Virtual Machine (JVM) to execute the Java code as a Web application on the Tomcat Web server. By default, the memory allocated to each Web application is set to 64 MB.
If you encounter slowdown on your Web application, try and increase the memory allocation for the JVM using the JAVA_OPTS environment variables in the setenv configuration file. There are two values to set in the setenv configuration file:
-Xms - the amount of memory that the JVM is allocated by default.
-Xmx - the maximum memory limit that the JVM allocates to a single Web application
On LINUX or UNIX platforms, open the setenv.sh file in Tomcat's \bin directory and set the memory values, as seen in this example:
export JAVA_OPTS="-Xms128m -Xmx512m"
For Windows platforms, On LINUX or UNIX platforms, open the setenv.bat file and set the memory values, as seen in this example:
set JAVA_OPTS=-Xms128 -Xmx512
Restart the Tomcat server to implement the new memory allocation values for Web applications.
and restart the Tomcat server.
