Re: multi-threaded pgbench - Mailing list pgsql-hackers

From Josh Williams
Subject Re: multi-threaded pgbench
Date
Msg-id 1248838716.6953.38.camel@lapdragon
Whole thread Raw
In response to Re: multi-threaded pgbench  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: multi-threaded pgbench
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: xpath not a good replacement for xpath_string
Next
From: Tom Lane
Date:
Subject: Re: plpgsql: support identif%TYPE[], (from ToDo)