.ExternalClass P
{padding:0px;}
.ExternalClass
{font-size:10pt;font-family:Tahoma;}
I'm not sure I understand the question. What else runs on it ?
I have an Apache that fronts a Tomcat (Java Enterprise App Server). In tomcat I only run this application that has a connection pool of 30 connections(if I remember correctly).
Once the application starts to open connections it looks that the each postmaster associated with the connection is not exiting as fast as was before. I can follow up with a ps -aux capture if you think that's helpful. Till yesterday all was working smoothly for about 2 years. It looks like the postmasters are not finishing of if they do takes a good while to finish. Also I've seen that the swap increases. I never use to have swap used. I don't have space problems not errors in the syslog.
Am I running out of memory and all gets delayed by the swap handling ? I have the feeling that I spin around my tail. So these processes are taking all the CPU and memory and they hold for too long just doing a select. The traffic didn't increase by any means so one can say that causes the problem - at one point it sustained 4 times more traffic without problems.
Hope this provide more insight.
MC
> Date: Fri, 8 Jun 2007 16:35:40 -0400 > From: ajs@crankycanuck.ca > To: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Postmaster processes taking all the CPU > > On Fri, Jun 08, 2007 at 03:20:28PM -0500, MC Moisei wrote: > > > > pack of postmaster(4-22) processes ran by postgres user are taking > > over almost all the CPU. > > What else is the box doing? If it doesn't have any other work to do, > why shouldn't postgres use the CPU time? (This is a way of saying, > "You didn't tell us anything that would allow us to help.") > > A > > -- > Andrew Sullivan | ajs@crankycanuck.ca > In the future this spectacle of the middle classes shocking the avant- > garde will probably become the textbook definition of Postmodernism. > --Brad Holland > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org/