sounds like you have a big big mainframe, so I also doubt the database server is an issue. Is there any firewall between tomcat and the database server? it could be the firewall is limiting the number of connections and therefore forcing the db connection pool to wait longer than it should to create a new connection.
beyond that, about the only way would be to start tomcat using a profiler and see exactly what is blocking. peter On 12/15/05, Marc Richards <[EMAIL PROTECTED]> wrote: > > No, the db is actually our world-wide enterprise > server. It's got plenty of capacity for handling many > hundreds of thousands of daily transactions. When I'm > pounding the web app I literally can not even see my > activity on the machine and the disk arms are all > calm. It's made for tougher stuff than I'll ever be > able to throw at it (due to JDE client programs being > so chatty, it's necessary to have a very powerful db > when you run OneWorld). > > It's kind of hard to track how many open db > connections there are from the db end because normally > there are many thousands to begin with and the number > fluctuates by leaps and bounds just as a course of > doing regular business. > > I'm not sure that my sessions are of too much concern > at the moment either because when I check the server > boxes I'm seeing that Tomcat is only using between 200 > and 400 mg of RAM and there is 4gb available. I don't > have a short session kill time (I think it's two hours > at the moment), but I am failing them out to disk > every few minutes, so inactive sessions should be > staying out of physical memory. And by the low memory > consumption of Tomcat under load, I'd say that part is > probably working ok (and also because I can see all of > the db records in the session table). > > I haven't gotten any complaints from the db on the > session table itself, but that doesn't mean that there > isn't collusion because there could be some locking > issues taking place that would cause session backups > and restores to take on some latency. The db won't > complain about a locking issue and I haven't been able > to find any myself, but due to the fact that each > connection appears to open, read/write and then > abandon, locks would come and go so quickly that I > probably wouldn't be able to see them anyway. > > I did notice that the db performance optimizer was > spending some extra time analyzing the sessions table, > but I think that's because it regularly gets a bunch > of records pumped to it and then it clears out as > sessions become invalidated. It's really quite > under-used compared to most of the JDE tables on the > system. > > I was concerned about the maxThreads for a time (and > actually did have a problem because Apache's was set > higher and puking when it over-ran). But I got tired > of tweaking for this and just set it at 5000 to see > what would happen. I think the default is only 50, so > I thought 10x would represent a 'big' site. Am I > wrong? It didn't change a thing by setting it that > high. How do you check the queue depth? I'm not sure > I'm familiar with that one... > > -
