On Tue, 2009-07-28 at 12:10 -0400, Greg Smith wrote:
> If your test system
> is still setup, it might be interesting to try the 64 and 128 client cases
> with Task Manager open, to see what percentage of the CPU the pgbench
> driver program is using. If the pgbench client isn't already pegged at a
> full CPU, I wouldn't necessarily threading it to help--it would just add
> overhead that doesn't buy you anything, which seems to be what you're
> measuring.
That's a really good point, I do recall seeing pgbench taking only a
fraction of the CPU... Running it again, it hovers around 6 or 7
percent in both cases, so it's only using up around half a core.
Huh, running the patched version on a single thread with 128 clients
just got it to crash. Actually consistently, three times now. Will try
the same thing on the development box tomorrow morning to get some
better debugging information.
> All the Linux tests suggest that limit tends up show up at over 20,000 TPS
> nowawadys, so maybe your Window system is bottlenecking somewhere
> completely different before it reaches saturation on the client.
I figured it was just indicating a limitation of the environment, where
Windows has some kind of inefficiency either in the PG port or just
something inherent in how the OS works. It does make me wonder where
exactly all that CPU time is going, though. OProfile, how I miss thee.
But that's a different discussion entirely.
- Josh Williams
