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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers