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: ajs@crankycanuck.ca
> 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 | ajs@crankycanuck.ca
> 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