Yes all the connection are coming from within the box so no network
latency.Well, isn't the swap can be because too many process postmaster are
requiring more memory. I will reproduce it and I'd try post a memory and
processes footprint. The reason I said I feel like spinning around the tail is
that if "something" delays my many postmasters would automatically feel my 2GB
off RAM and take over the CPU and eventually swap.Thanks for getting back to
me, much appreciated.MC> Date: Fri, 8 Jun 2007 17:55:26 -0400> From: [EMAIL
PROTECTED]> To: pgsql-general@postgresql.org> Subject: Re: [GENERAL] Postmaster
processes taking all the CPU> > First, your mail is coming through really
garbled. Maybe you need to> add some linebreaks or something? Anyway> > On
Fri, Jun 08, 2007 at 03:58:40PM -0500, MC Moisei wrote:> > > > 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> > All on the same box? And maybe you better check
exactly how it's> configured if you want support, eh?> > > 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> > If you're into swap, that suggests you are
running out of memory. > That'd explain just about everything. Have you tuned
postgres so> that it can use more memory than you actually have? After two
years,> I'd expect the data to be larger, which might mean you have reached>
some threshold where an optimisation you made that wasn't actually> right is
now really wrong. If you're swapping, the CPU time is> probably going to
bringing some data back in from disk (i.e. it's> actually in OS calls).> > A> >
-- > Andrew Sullivan | [EMAIL PROTECTED]> I remember when computers were
frustrating because they *did* exactly what > you told them to. That actually
seems sort of quaint now.> --J.D. Baldwin> >
---------------------------(end of broadcast)---------------------------> TIP
9: In versions below 8.0, the planner will ignore your desire to> choose
an index scan if your joining column's datatypes do not> match