Also.. if you have 120MB memory 'left', and it doesn't seem to be wanting any more, but it slowly but surely "slows down"... this is not the typical description of a 'not enough memory' problem.
If anything, it might be connector related. If you use Apache as a frontend to Tomcat, are there enough jk connectors? Do you use a database, and do you have enough connections to it? That sort of thing.
Something within your app is "waiting" for a free resource. It's not a question of memory if the 'free memory' does not decrease.
Joined: May 05, 2004
Thanks Mike for your reply, well if i understand correctly Tomcat doesn't need more memory, and the JVM neither. As tomcat is used as httpd front end it's not a connector problem. Now my guess is the slowdown is coming from the JSPs waiting for the database connection. I'm using Mysql, and I know there are many so called 'slow queries' (queries taking more than 4sec). While Mysql is optimized to stand 450 connections max, tomcat is optimized to get 350 connections max : <Connector port="80" maxThreads="350" minSpareThreads="25" maxSpareThreads="95" enableLookups="false" redirectPort="8443" acceptCount="200" debug="0" connectionTimeout="15000" disableUploadTimeout="true" /> May be this 100 connections difference cause the slow down... Now the other idea would be to optimize code itself and the way my JSP connects to the database. First : i really checked all my code and all my sql objects are properly closed, so it should not wait for the GC to get rid of them Second : each JSP loads the driver and makes a connection to the DB Class.forName("org.gjt.mm.mysql.Driver"); Connection con; con = DriverManager.getConnection(url); I choosed not to use a database pooling. Why ? The driver is already loaded, unless it's the first time, there should not be any delay to call it again. A new object connection is created (con = DriverManager.getConnection(url) , but I guess a new connection is also done when using a database pooling, even if I use commons.dbcp > getConnection(). I'm not completely convinced by using database pooling, and I'd like to discuss database related performance problem with some people, is there a forum available for this topic here ? Last but not the least, changing the driver itself... but mm.mysql is still a good open source one...
You really should investigate database pooling. It turns out that obtaining a db connection is a very slow process - thats why pooling was invented, to keep connections in use once they are opened. A pooling library manages a set of open connections, handing them out for temporary use and restoring them to the pool when you are done. I bet it will fix your problem. Bill Take a look at the JDBC forum near the top of the forum list. [ May 05, 2004: Message edited by: William Brogden ]
I choosed not to use a database pooling. Why ? The driver is already loaded, unless it's the first time, there should not be any delay to call it again.
Yea, driver is already loaded, but to create Connection costs a lot. e.g., it may be related to instantiaion of an underlying physical connection and buffer. A commerical-class application is always associated with multithreaded database and database pool.
A new object connection is created (con = DriverManager.getConnection(url) , but I guess a new connection is also done when using a database pooling, even if I use commons.dbcp > getConnection().
The benefit of pool is: a. maintain a number of connections in pool b. don't release that connection when you close it c. refuse request when no connection is available