This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
We just experienced db crash & loss of data, etc...
Our problem is that once our dba got the system back up,
everything is slow & he is blaming it on tomcat & java db pooling.
what we are seeing in oracle is that tomcat has about
~200-300 sleeping processes in oracle & ~50-100 active ones.
This is taxing our system as cpu is 90+ & load is 100+,
of course tomcat isn't the only thing hitting the db ...
my question is that given our large client base this does not seem
unusual. what do 'sleeping' processes (these are tomcat processes)
in oracle mean? is it oracle's way of caching requests ...
we use db pooling:
with max 60 connections & this is never exceeded & has worked in the past.
all of our conn are closed properly, code is cleaned, etc ...
but our dba is blaming the dev team saying its tomcat/java where as i
see it as our hardware just sucks plus we had 3 db servers now we are
down to 2.
anyways is this unusually large amount of 'sleeping' processes within
oracle ? should we use a better pooling mechanism.
any thoughts much appreciated
Joined: Apr 18, 2007
figured it out;
tomcat connects to oracle in dedicated mode.
with connection pooling implemented in tomcat and with ~5 front end servers we get about 5*100 = 500
dedicated processes in oracle specifically for tomcat.
majority are sleeping since the 'connection' remains open until tomcat is shut down.
apparently sleeping processes consume a minimal amount of resources and add to the overall db server load ...
and our hardware just sucks. Anyways this might be useful for someone else down the line ...
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com