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.
Tcat Server's management console gives you deep visibility into the memory stats of your Tomcat instances, allowing you to eliminate memory leaks and tune your servers more quickly than ever. Download Tcat Server today!
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 Tomcat 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.
More Here
Courtesy:http://www.mulesoft.com/tomcat-memory