Today, my colleagues from the new energy Test team came to me to see a strange phenomenon. A tomcat application with only a single JSP page, and this JSP page does not have any Java code (want to use this JSP page to test the maximum QPS of a tomcat on her server). But after a few minutes of loadrunner pressure, a 1024M heap of RAM was allocated to the heap space outofmemory! 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>
The initial analysis was that a JSP page would die and produce a corresponding Java file, which would then be compiled into a class file and loaded into memory. That is, a class object will be loaded into the PermGen space. It has nothing to do with heap space. But the final report is the overflow of space. So the guess is that every time a JSP page is requested, an object is generated.
Baidu a bit, found that every time a JSP page request, will produce a session object. There's this configuration in Tomcat's Web.xml:
The
code is as follows:
<session-config>
<session-timeout>30</session-timeout>
</session-config>
That is, every time a JSP page is requested, a session object is generated, and the object expires after 30 minutes. We calculated that the QPS at that time was 5000, which means that 5,000 session objects per second are generated. Each minute produces 300K objects, the session is a map object, larger, so that memory will soon burst.
The solution is as follows:
1. Add Session=false to the page directive.
2. Set the expiration time of the session to 0.
Now her loadrunner is running very steady. After work has never used JSP, check JSP problem or more laborious