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

Re: write barrier question

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Samuel Gendler <sgendler(at)ideasculptor(dot)com>
Cc: Yeb Havinga <yebhavinga(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: write barrier question
Date: 2010-08-28 10:17:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
2010/8/19 Samuel Gendler <sgendler(at)ideasculptor(dot)com>:
> On Wed, Aug 18, 2010 at 1:25 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>> Samuel Gendler wrote:
>>> When running pgbench on a db which fits easily into RAM (10% of RAM =
>>> -s 380), I see transaction counts a little less than 5K.  When I go to
>>> 90% of RAM (-s 3420), transaction rate dropped to around 1000 ( at a
>>> fairly wide range of concurrencies).  At that point, I decided to
>>> investigate the performance impact of write barriers.

I have just tested a similar hardware (32GB RAM), I have around 15k
tps with a database wich fit in RAM (around 22GB DB).
The request and schema are very simple.

My advice is too use a pgbouncer on a separate server as well as any
benchmark. For very heavy bench I use 'tsung' benchmark tool.
Also some of your postgresql.conf params looks strange : shared_buffer
>8GB is probably working less well.

You may want to fine tune OS for Dirty cache (and dirty write) and/or
increase bgwriter agressivity.

It may happen that your overall performance are better with a mount -o
sync option ! (depend of your write usage, see iostat -x 2, especially
the Wtps, during checkpoints) Perc6i handle well the write cache and
you can use 'nobarrier' mount option too but mounting the filesystem
'sync' is not that bad (because the perc6 will buffer).

>> At 90% of RAM you're probable reading data as well, not only writing.
>> Watching iostat -xk 1 or vmstat 1 during a test should confirm this. To find
>> the maximum database size that fits comfortably in RAM you could try out
>> - my experience with it is that it
>> takes less than 10 minutes to setup and run and after some time you get
>> rewarded with nice pictures! :-)
> Yes.  I've intentionally sized it at 90% precisely so that I am
> reading as well as writing, which is what an actual production
> environment will resemble.
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:

Cédric Villemain               2ndQuadrant     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-performance by date

Next:From: Volodymyr KostyrkoDate: 2010-08-29 13:18:22
Subject: array can be slow when joining?
Previous:From: Craig JamesDate: 2010-08-28 00:41:53
Subject: Re: Using Between

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