Solution to tomcat memory overflow caused by a JSP page
Today, my colleagues in the New Energy testing group asked me to see a strange phenomenon. A tomcat application has only one simple jsp page, and the jsp page does not have any java code (you want to use this jsp page to test the maximum QPS of tomcat on her server ). However, after a few minutes of stress testing with loadrunner, the tomcat package heap space outofmemory allocated with MB heap memory exists! The code for this page is as follows:
The Code is as follows:
<% @ Page language = "java" contentType = "text/html; charset = ISO-8859-1"
PageEncoding = "ISO-8859-1" %>
<! DOCTYPE html PUBLIC "-// W3C // dtd html 4.01 Transitional // EN" "http://www.w3.org/TR/html4/loose.dtd">
<Html>
<Head>
<Meta http-equiv = "Content-Type" content = "text/html; charset = ISO-8859-1">
<Title> test </title>
</Head>
<Body>
<P> hello world! </P>
</Body>
</Html>
In the initial analysis, when a JSP page crashes, a corresponding java file is generated. Then, the java file is compiled into a class file and loaded into the memory. That is, a class object will be loaded into the PermGen space. It has nothing to do with heap space. However, the final message is a space overflow. Therefore, it is assumed that an object will be generated every time a jsp page is requested.
Baidu finds that a session object is generated every time a JSP page is requested. The following configuration is available in tomcat web. xml:
The Code is as follows:
<Session-config>
<Session-timeout> 30 </session-timeout>
</Session-config>
That is to say, a session object is generated every time a jsp page is requested, and the object expires 30 minutes later. We calculated that the QPS at that time was 5000, that is, 5000 session objects were generated every second. K objects are generated every minute, and the session is a map object, which is relatively large, so that memory will pop up soon.
The solution is as follows:
1. Add session = false to the page command.
2. Set the expiration time of the session to 0.
Now her loadrunner runs very stably. Jsp is no longer used after work. It is still laborious to query jsp problems.