Date: Fri, 3 Apr 2009 22:35:58 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: David Kerr <dmk@mr-paradox.net>, pgsql-performance@postgresql.org
Subject: Re: Question on pgbench output 
In-Reply-To: <24809.1238799146@sss.pgh.pa.us>
Message-ID: <alpine.GSO.2.01.0904032228180.25708@westnet.com>
References: <20090403195302.GA54342@mr-paradox.net>
	<alpine.GSO.2.01.0904031721570.5502@westnet.com>
	<24809.1238799146@sss.pgh.pa.us>
User-Agent: Alpine 2.01 (GSO 1184 2008-12-16)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

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@gregsmith.com http://www.gregsmith.com Baltimore, MD