> > > You may try to figure out what's the process doing (the backend
> > > obviously, not the frontend (Tcl) process) by attaching
> to it with
> > > strace.
> >
> > It's so sad when us poor Windows guys get helpful hints from people
> > assume that we're smart enough to run *NIX... ;-)
>
> You should try a google search on strace and NT or windows or
> XP... I was surprised how many various implementations of it I found.
Let me know if you find one that's stable, I've been wanting that. I've
tried one or two, but it's always been just a matter of time before the
inevitable BSOD.
> > > Maybe it's swamped by a context switch storm (but in that case,
> > > probably the other processes would be affected as well).
> >
> > What is a context switch storm? (and what a great name for a heavy
> > metal rock band!)
>
> I can just see the postgresql group getting together at the
> next O'Reilley's conference and creating that band. And it
> will all be your fault.
*DO NOT LET DEVRIM SEE THIS THREAD*
> A context switch storm is when your machine spends more time
> trying to figure out what to do than actually doing anything.
> The CPU spends most it's time switching between programs
> than running them.
I can see Windows benig more sucepitble to this than say Linux, because
switching between processes there is a lot more expensive than on Linux.
> Seeing as PostgreSQL runs one thread / process per
> connection, it's pretty unlikely that the problem here is one
> "hungry" thread. Do all four CPUs show busy, or just one?
> Do you have a way of measuring how much time is spent waiting
> on I/O on a windows machine like top / vmstat does in unix?
There are plenty of counters in the Performance Monitor. Specificall,
look at "disk queue counters" - they indicate when the I/O subsystem is
backed up.
//Magnus