--- "Petkov, Rossen" <[EMAIL PROTECTED]> wrote: > Hello, > I am having a problem with Tomcat 5.0.19 on > windows with JDK > 1.4.2_03.The memory that java.exe is using keeps > growing till the point > that tomcat > Runs out of memory. > Using a profiler, doesn't seem to help me much. > I can see the memory > being used by certain classes go up (mainly char[] > and byte[] and some > tomcat classes, please see the tables below) and > even reach all the way > to the point that used java heap equals to the java > heap, then GC > probably kicks but, while running Tomcat throws an > OutOfMemory > exception. I have allocated -Xmx896M. I'm now > forcing a GC when the > free memory drops to 15%. With every GC, the freed > memory is less and > less, which to me is an indication of memory leak. > I can't figure out where all those char[] objects > are coming > from or why they aren't being reclaimed by the > garbage collector. I > know that something is holding memory and isn't > letting it go, and I > know that the leaked memory consists of char[] and > byte[] objects (see > below tables). What I can't figure out is how to > determine what's doing > the leaking. > After several hours of heavy usage, the GC runs and > frees less > memory than the previous run. This gives me on day > of normal operation > and I have to restart Tomcat after hours to be ready > for the next day, > not a really acceptable solution. > I noticed the 3 tomcat classes: > org.apache.tomcat.util.buf.MessageBytes, > org.apache.tomcat.util.buf.ByteChunk and > org.apache.tomcat.util.buf.CharChunk. The memory > occupied my these seems > to never be released. Can they be the cause of the > multiple byte[] and > char[]? > > Some info about the application/environment: > - Tomcat 5.0.19 on windows with JDK 1.4.2_03. > - MVC type web application > - front Controller dispathing requests to > business classes and > forwards to appropriate JSP, passing necessary data > objects in the > request object > - heavy JDBC use and DAO/DTO components, mainly > using > PreparedStatement > - Oracle stored procedures and functions > acccessed thru > CallableStatement > - Oracle database > > I am doing the usual for closing all jdbc database > related objects like > ResultSet, PreparedStatement and connections. > Here are some thoughts that I have, that could be > the reason for the > leak, these are more questions: > 1. DTO objects are being passed from the data layer > to the > business layer and finnaly to the JSP. After using > the DTOs on the JSP, > they are not explicitly set to null in the JSP. I > see that all DTO > declarations are in the "service" method of the > compiled JSPs. Can this > be a problem? > 2. HashMaps, HashTables and LinkedHashMaps are > being passed the > same way thru the layers and end up in the JSPs. > These are not set to > null either. Can this be a problem? > 3. PreparedStatement and CallableStatement are > always closed, > but not always set to null. > Can any of these be the cause? > > > Below are some metrics from my environemnt: > After a several hours of heavy usage, BEFORE GC: > > Name > Instance count Size > char[ ] > 2,200,184 425,721 > kB > byte[ ] > 199,003 178,902 > kB > java.lang.String > 1,825,003 42,773 > kB > java.lang.StringBuffer > 925,351 21,687 > kB > <class>[ ] > 679,935 19,181 > kB > org.apache.naming.resources.FileDirContext$FileResourceAttributes > 122,254 8,595 kB > org.apache.tomcat.util.buf.MessageBytes > 117,876 5,525 > kB > org.apache.tomcat.util.buf.ByteChunk > 135,061 5,275 > kB > org.apache.tomcat.util.buf.CharChunk > 132,558 5,178 > kB > java.util.HashMap$ValueIterator > 97,551 3,04 > ...more > > > > AFTER GC: > This is the top of the list, sorted by size: > > Name > Instance count Size > byte[ ] > 47,866 167,877 > kB > char[ ] > 69,387 151,906 > kB > org.apache.tomcat.util.buf.MessageBytes > 117,928 5,527 > kB > org.apache.tomcat.util.buf.ByteChunk > 135,120 5,278 > kB > org.apache.tomcat.util.buf.CharChunk > 132,616 5,180 > kB > <class>[ ] > 71,550 4,711 > kB > int[ ] > 22,195 1,408 > kB > java.text.DecimalFormat 7,351 > 804 kB > java.lang.String > 32,828 769 kB > org.apache.tomcat.util.http.MimeHeaderField > 28,098 658 kB > java.util.HashMap > 15,598 609 kB > java.util.GregorianCalendar 7,351 > 516 kB > long[ ] 4,927 > 498 kB > java.text.DecimalFormatSymbols 7,351 > 402 kB > ...more > > As you can see, one third of the char[] and almost > all of the byte[] > remain after the GC. As for the three tomcat > classes, they remain almost > unchanged. > > All your input will be much appreciated! > Regards, > Rossen Petkov > [EMAIL PROTECTED] > TMaG Carlsbad > 1.760.918.6228
I would start with reading the fix lists for version after yours. 5.0.19 is not new by any way of reasoning, so I would search bugs fixed in that branch after that version number for a starter. Next, are you doing anything with StringBuffer, char[], Strings where you are storing them off into a Map or List or something similar? What are you doing with Session objects? Are you able to test with a single page which access some functionality? Does this occur with every page or do you see memory really growing when you are hitting certain ones? I think you'll need to get better information or at least more than this before you will be able to get useful information from others without their hands on your environment, application, and source. If you debug your application do you see anything that is not cleaned up during the life cycle of a user (look at any containers of any kind maps, lists, vectors, arrays, etc)? Wade --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
