Horton

Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)

Alvaro Herrera <alvherre@commandprompt.com>

View thread
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, pgsql-hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2011-06-14T04:09:49Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid extra system calls to block SIGPIPE if the platform provides either

Excerpts from Jeff Janes's message of lun jun 13 20:27:15 -0400 2011:
> On Mon, Jun 13, 2011 at 7:03 AM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc> wrote:
> ...
> >
> >
> > so it seems that sysbench is actually significantly less overhead than
> > pgbench and the lower throughput at the higher conncurency seems to be
> > cause by sysbench being able to stress the backend even more than
> > pgbench can.
> 
> Hi Stefan,
> 
> pgbench sends each query (per connection) and waits for the reply
> before sending another.

I noticed that pgbench's doCustom (the function highest in the profile
posted) returns doing nothing if the connection is supposed to be
"sleeping"; seems an open door for busy waiting.  I didn't check the
rest of the code to see if there's something avoiding that condition.  I
also noticed that it seems to be very liberal about calling
INSTR_TIME_SET_CURRENT in the same function which perhaps could be
optimizing by calling it a single time at entry and reusing the value,
but I guess that would show up in the profile as a kernel call so it's
maybe not a problem.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support