We're using the latest jdk 1.5 release (the server version of the JVM) and currently do have the heap min/max set to 1024 . I'll try the other jvm options related to GC. I know we tried -Xincgc to no effect.
We are indeed seeing OutofMemoryExceptions, but at this point the app has a few other problems, that I don't believe are related to the compression, so the logfiles are pretty confusing (and the app is catching most Exceptions, and only printing the message of the exception, not the stacktrace). What is stumping me a bit is that Tomcat flat out dies with no conclusive messages in the logs. My best theory so far is that the Gzip filter I mentioned below may be allocating at least 4 objects, each with a copy of the entire (compressed) response. Each request is grabbing 100K increments of a larger file, but the files can get somewhat large (2-3M) The filter is basically a SerlvetOutputStream that passes all the writes to the GZIPOutputStream which is wrapping a ByteArrayOutputStream. When the ServletOutputStream is closed, it gets the byte array from the ByteArrayOutputStream, converts it to a String, and writes it to the original HttpResponse. This is probably running down the free memory in the JVM pretty quickly, causing the gc to run not only frequently while the server is under heavy strain, but also each time it is freeing up alot of memory. That's why I'm very curious to find out in greater detail exactly how the "compress" option is working. I'll take a look at the code again as well, but if anyone has any experience using the filter from the O'Reilly book (this is the second time I've seen it used in apps), and in particular how the Tomcat implementation behaves, I'd greatly appreciate it. "Derrick Koes" <[EMAIL PROTECTED]> 09/09/2006 08:10 AM Please respond to "Tomcat Users List" <users@tomcat.apache.org> To "Tomcat Users List" <users@tomcat.apache.org> cc Subject RE: Question about the "compress" setting MIME-Version: 1.0 Sounds like a bandwidth/throughput problem if you are concerned with the connector compression attribute. You may want to try some performance tuning with the throughput garbage collector. Assuming your problem is an OutOfMemory Error and at least Java 1.4.1, try the following VM settings -Xmn=1024m -Xmx=1024m -XX:+AggressiveHeap -XX:+UseParallelGC -XX:MaxPermSize=128m Below is reference documentation. http://java.sun.com/docs/hotspot/gc1.4.2/ http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html If you still have memory problems, try a memory profiler like Jprofiler to detect memory leaks as well as CPU issues. http://www.ej-technologies.com/products/jprofiler/overview.html It would be helpful if you posted any errors in the log files when you incur the issue. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, September 09, 2006 1:33 AM To: users@tomcat.apache.org Subject: Question about the "compress" setting MIME-Version: 1.0 We currently have an app in prod using the original servlet filer described at http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html?page=3 , and I know from the comments to the article in the link that there may be some issues with it. My question is; how does the built-in tomcat implementation, which is activated by the compress="true" attribute on the default http1.1 connector improve on the servlet filter mentioned above. For context, I should mention that we're running on Windows 2003 server, sp1 using Apache Tomcat/5.0.28 on on dual Intel Xeon processor with 4Gb of RAM. Under various memory settings ranging from giving the heap from any interval of 800 - 1500 MB of heap space, the Tomcat server will die more or less silently under even moderate load (heavy load kills it almost immediately). Any help would be appreciated, and as I've mentioned (username jmonstad) on the IRC channel, I may be willing to entertain engagements from local to Minneapolis, US gurus for $'s --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
