Skip site navigation (1) Skip section navigation (2)

Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Nils Goroll <slink(at)schokola(dot)de>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux
Date: 2012-07-01 12:23:06
Message-ID: CA+TgmoYBmgT8t4koX_deKPFbn-xP3xXgL87T+ruUNTY9MNERfQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jun 29, 2012 at 1:07 PM, Nils Goroll <slink(at)schokola(dot)de> wrote:
>> FWIW, I kicked off a looong benchmarking run on this a couple of days
>> ago on the IBM POWER7 box, testing pgbench -S, regular pgbench, and
>> pgbench --unlogged-tables at various client counts with and without
>> the patch; three half-hour test runs for each test configuration.  It
>> should be done tonight and I will post the results once they're in.
>
> Sounds great! I am really curious.

Here are the results.  Each result is the median of three 30-minute
test runs on an IBM POWER7 system with 16 cores, 64 hardware threads.
Configuration was shared_buffers = 8GB, maintenance_work_mem = 1GB,
synchronous_commit = off, checkpoint_segments = 300,
checkpoint_timeout = 15min, checkpoint_completion_target = 0.9,
wal_writer_delay = 20ms, log_line_prefix = '%t [%p] '.  Lines
beginning with m show performance on master; lines beginning with p
show performance with patch; the following number is the # of clients
used for the test.

Permanent Tables
================

m01 tps = 1364.521373 (including connections establishing)
m08 tps = 9175.281381 (including connections establishing)
m32 tps = 14770.652793 (including connections establishing)
m64 tps = 14183.495875 (including connections establishing)
p01 tps = 1366.447001 (including connections establishing)
p08 tps = 9406.181857 (including connections establishing)
p32 tps = 14608.766540 (including connections establishing)
p64 tps = 14182.576636 (including connections establishing)

Unlogged Tables
===============

m01 tps = 1459.649000 (including connections establishing)
m08 tps = 11872.102025 (including connections establishing)
m32 tps = 32834.258026 (including connections establishing)
m64 tps = 33404.988834 (including connections establishing)
p01 tps = 1481.876584 (including connections establishing)
p08 tps = 11787.657258 (including connections establishing)
p32 tps = 32959.342248 (including connections establishing)
p64 tps = 33672.008244 (including connections establishing)

SELECT-only
===========

m01 tps = 8777.971832 (including connections establishing)
m08 tps = 70695.558964 (including connections establishing)
m32 tps = 201762.696020 (including connections establishing)
m64 tps = 310137.544470 (including connections establishing)
p01 tps = 8914.165586 (including connections establishing)
p08 tps = 71351.501358 (including connections establishing)
p32 tps = 201946.425301 (including connections establishing)
p64 tps = 305627.413716 (including connections establishing)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Kohei KaiGaiDate: 2012-07-01 14:53:47
Subject: Re: [v9.3] Row-Level Security
Previous:From: Alexander KorotkovDate: 2012-07-01 11:11:52
Subject: Re: [PATCH 14/16] Add module to apply changes from an apply-cache using low-level functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group