I have observed the tomcat 7 process memory (private bytes) was initially 1.2 GB during startup and it got increased to 3.5 GB where my server RAM size is only 4GB after running a 100 users test for 4 hours. this private bytes was not released even after stopping the test. could you please let us know any configurations that might help this or kindly analyze the situation and provide your suggestions/solutions.
Lacking more specific about the behavior that you are seeing and about the environment that you are using to run your tests, and since this is a testing environment, my suggestion to you would be to run your tests while you have a profiler hooked up to Tomcat (YourKit is an excellent profiler). The profiler will allow you to look for memory problems in your application.
That's not to say there is definitely a problem here. It is entirely possible that you could see the heap grow from 1.2 G to 3.5G legitimately. It just depends on your JVM options and the memory demands of your application.
For organizations with large publically searchable websites, such as those found in ecommerce companies with large product catalogues or companies with active online communities, web crawlers or bots can trigger the creation of many thousands of sessions as they crawl these large sites. Normally crawling sites without relying on cookies or session IDs, these bots can create a session for each page crawled which, depending on the size of the site, may result in significant memory consumption. New in Apache Tomcat 7, a Crawler Session Manager Valve ensures that crawlers are associated with a single session - just like normal users - regardless of whether or not they provide a session token with their requests.
One of the roles I play in the Apache Tomcat project is managing the issues.apache.org servers which run the two Apache issue trackers we have—two instances of Bugzilla and one instance of JIRA. Not surprisingly, JIRA runs on Tomcat. A few months ago, while looking at the JIRA management interface, I noticed that we were seeing around 100,000 concurrent sessions. Given that there are only 60,000 registered users and less than 5,000 active users any month, this number appeared extremely inflated.
After a bit of investigation, the access logs revealed that when many of the webcrawlers (e.g., googlebot, bingbot, etc) were crawling the JIRA site, they were creating a new session for every request. For our JIRA instance, this meant that about 95% of the open sessions were left over from a bot creating a single request. For instance, a bot requesting 100 pages, would open 100 sessions. Each one of these requests would hang around in memory for about 4 hours, chewing up tremendous memory resources on the server.
2010 has been an exciting year for the Tomcat Expert community site. Created by the Apache Tomcat Experts at SpringSource, Tomcat Expert was launched in March to improve the adoption, performance and value of Apache Tomcat for enterprise users. After almost ten months of operation, we’ve been able to provide you with content from Tomcat Expert Contributors weighing in on top Apache Tomcat news and topics, including several relating to June's release of Tomcat 7.0.0 Beta, the first Tomcat 7 release. As the year winds down, we've put together a list of the most popular blog posts of the year. Additionally, we're asking you to tell us what topics you'd like to see covered more in 2011 with a content request form below.
We’re here today with Mark Thomas, Apache Tomcat Committer and Release Manager for Tomcat 7.
Andy: Thanks for spending the time with me this evening. Congratulations to you and the Tomcat Community for achieving the Beta milestone for Release 7. We’re hearing interest from our clients, and it looks like there is lots of good stuff in this release.
I understand that you are "Release Manager", as well as committer, for Tomcat 7...what does that role entail?
Mark: The Tomcat community has traditionally had a 'fixed' release manager for each major branch. It is fixed in that the same person does it for several releases in a row but in theory any committer could start a release at any point. As release manager, I build the release (do a clean checkout from svn and then 'ant release'), upload the release to a staging area and then call a vote on the dev list.
If the vote passes, I copy the files from the staging area to the distribution area, update the download links, update the latest version information on the Tomcat homepage, upload the maven artifacts and send out the release announcement to the lists. It sounds like a lot of work, but it is 99% automated.
Much more effort goes into the voting phase, where we check the release quality.
Tomcatexpert.com contributors are all professional developers, most of whom perform contracts with other companies. Inevitably, when these pros get out in the field, other developers, hoping to learn some secret sauce, ask them about their preferred developer setup. So in the interest of sharing, we've pulled together a list of the top tools our Tomcatexpert.com contributors use in their daily dev environments.
File locking in Windows may prevent the directory from being deleted.
File locking on Windows is different than file locking on Unix in that on Windows a file can be locked on read. If you are redeploying a second version of an already deployed web application, you may see something like the following web application:
Often times a developer or operations professional needs access to monitor a Tomcat instance for purposes of capacity planning, troubleshooting, and performance tuning. There are many tools available already for Tomcat, some of them open source, and others paid for. Some tools are simple and others are complex management suites.
There are comprehensive monitoring suites available that monitor and manage Tomcat, and do it well; however, there is always a benefit to being able to create your own custom Tomcat/application management tools. The first advantage is that you get exactly what you want out of your utility. In my example, I wanted to have a way to browse a Tomcat server’s Java Management Extensions’ MBeans with a hierarchical, bash-like navigation. This allows me to quickly find and diagnose problems with my Tomcat server or custom applications running within Tomcat, and is more precise than trending those MBeans over time using a more comprehensive monitoring suite. I liken it to purchasing a ready-made suit, or having one custom tailored to your exact specification. It just feels better sometimes, and other times it is not practical.
Many utilities will not provide the specific feature that you need. There are usually a host of open source or commercial utilities for anything that one goal any developer or operations professional may want to achieve; however, often times that utility will not integrate well into their existing infrastructure, or not play well with automated processes that are pre-existing in the enterprise. In such cases, a custom utility can come in handy. Writing your own tools from scratch is a quick solution to a specific problem, and cuts out a lot of the fat. For simple tools, the complexity risk argument just isn't there, and in the time it takes to write a simple custom application.
If you've recently upgraded the RAM, or are moving your Tomcat applications to a larger box, you may want to update your allocated memory.
To find out how much RAM is allocated already to your Tomcat instance, if you have Tomcat installed as a Windows service, you can run Regedit and look at:
HKEY_LOCAL_MACHINE SOFTWARE Apache Software Foundation Procrun 2,0
Under that key will be all the tomcat service instances you have installed on that machine. If you expand an instance tree you will see another key named Parameters. Expand this and you will see a number of named values:
The short answer is that this is a myth. The longer answer is that back in the days of Tomcat 3 there was some truth to this depending on circumstances. However, for the versions of Tomcat in use today (5.5.x and 6.0.x) then there is no need to use httpd for purely performance reasons. Tomcat now supports the native/APR connector which uses the same native library (the Apache Portable Runtime—APR) as httpd for the low-level I/O and therefore can achieve similar performance to httpd. When serving static content there is ever so slightly more overhead when using Tomcat compared to httpd but the differences are so small they are unlikely to be noticeable in production systems.
If you research the httpd vs Tomcat performance issue, you will find a variety of load and performance benchmarks that show a range of results. An often quoted result shows that Tomcat's pure Java connector is consistently faster than httpd.
This particular result is the opposite of what is expected. httpd should be significantly faster than Tomcat's pure Java connector. This result is probably caused by the size of the file used. Tomcat caches small static files in memory by default and this will provide a significant performance improvement. httpd does not cache files in memory by default. This demonstrates quite nicely how the definition of the benchmark can have a significant impact on the results.
For development and operations teams, a presentation that covers performance tuning Tomcat and the JVM alongside configuration options, load balancing, and more.
In this webinar, Apache Tomcat committers Mark Thomas and Filip Hanik discuss performance tuning Apache Tomcat for your production environment. This webinar focuses on Tuning Tomcat and the JVM to correctly handle your application including usage patterns, hardware and network topology. You’ll learn when and how to apply the different tuning and configuration options as well as understanding load balancers and how they can impact your configuration settings. Also discussed: the impact of clustering and replication on your environment.