> > > 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
