Re: improving concurrent transactin commit rate

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: improving concurrent transactin commit rate
Date: 2009-03-25 18:48:03
Message-ID: 20090325184803.GG8566@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 25, 2009 at 05:56:02PM +0000, Sam Mason wrote:
> On Wed, Mar 25, 2009 at 12:01:57PM -0500, Kenneth Marshall wrote:
> > On Wed, Mar 25, 2009 at 03:58:06PM +0000, Sam Mason wrote:
> > > #!/bin/bash
> > > nclients=$1
> > > ittrs=$2
> > > function gensql {
> > > echo "INSERT INTO bm (c,v) VALUES ('$1','0');"
> > > for (( i = 1; i < $ittrs; i++ )); do
> > > echo "UPDATE bm SET v = '$i' WHERE c = '$1';"
> > > done
> > > echo "DELETE FROM bm WHERE c = '$1';"
> > > }
> > > for (( c = 0; c < $nclients; c++)); do
> > > gensql $c | psql -Xq -f - &
> > > done
> > > for (( c = 0; c < $nclients; c++)); do
> > > wait
> > > done
> >
> > Are you sure that you are able to actually drive the load at the
> > high end of the test regime? You may need to use multiple clients
> > to simulate the load effectively.
>
> Notice that the code is putting things into the background and then
> waiting for them to finish so there will be multiple clients. Or maybe
> I'm misunderstanding what you mean.
>
> I've just tried modifying the code to write the generated SQL out to
> a set of files first and this speeds things up by about 6% (the 48
> client case goes from taking ~42 seconds to ~39 seconds) indicating that
> everything is probably OK with the test harness. Also note that this 6%
> improvement will be linear and across the board and hence should just
> appear as slightly reduced performance for my system. As I'm not really
> interested in absolute performance and more in how the system scales as
> load increases this will negate this effect even further.
>
> --
> Sam http://samason.me.uk/
>

I did notice how your test harness was designed. It just seemed that
the actual process contention on your load generation system will actually
bottle-neck as the number of clients increases and that may be the cause
of your fall-off, or a contributor. You could test it by generating the
load from independent boxes and see how the perfomance falls-off as you
add additional load clients+boxes.

My two cents,
Ken

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-03-25 19:17:23 Re: shut down pgsql-interfaces (was Re: [HACKERS] Function C and INOUT parameters)
Previous Message Josh Berkus 2009-03-25 18:39:09 Mentors needed urgently for SoC & PostgreSQL Student Internships