From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Kerr <dmk(at)mr-paradox(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Question on pgbench output |
Date: | 2009-04-04 02:35:58 |
Message-ID: | alpine.GSO.2.01.0904032228180.25708@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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 gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Carey | 2009-04-04 05:24:52 | Re: Raid 10 chunksize |
Previous Message | Greg Smith | 2009-04-04 02:26:49 | Re: Raid 10 chunksize |