On Fri, 3 Apr 2009, Tom Lane wrote:
However, I don't think anyone else has been pgbench'ing transactions
where client-side libpq has to absorb (and then discard) a megabyte of
data per xact. I wouldn't be surprised that that eats enough CPU to
make it an issue. David, did you pay any attention to how busy the
pgbench process was?
I certainly haven't ever tried that. David, the thing you want to do here
is run "top -c" when pgbench is going. You should see the pgbench process
and a bunch of postmaster ones, with "-c" (or by hitting "c" while top is
running) you can even see what they're all doing. If the pgbench process
is consuming close to 100% of a CPU's time, that means the results it's
giving are not valid--what you're seeing in that case are the limitations
of the testing program instead.
You can even automate collection of that with something like this:
top -b -d 10 -c -n 10000 > top.log &
TOPPID=$!
(run test)
kill $TOPPID
That will save a snapshot every 10 seconds of what's happening during your
test.
--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
