From: Merlin Moncure <mmoncure@gmail.com>
To: andy rost <andy.rost@noaa.gov>
Cc: pgsql-performance@postgresql.org
Cc: Bill.Sites@noaa.gov
Cc: jeff@frostconsultingllc.com
Subject: Re: Opteron/FreeBSD/PostgreSQL performance poor
Date: Sun, 9 Jul 2006 10:47:52 -0400
Message-ID: <b42b73150607090747i27a282b6u6c1fda4efcb2f3fe@mail.gmail.com> (raw)
In-Reply-To: <44AECDFD.4030502@noaa.gov>
References: <44ABCFF4.3010007@noaa.gov>
<b42b73150607060744u54a6ea93la0e56da3828e0a13@mail.gmail.com>
<44AECDFD.4030502@noaa.gov>
On 7/7/06, andy rost <andy.rost@noaa.gov> wrote:
> Hi Merlin,
> Thanks for the input. Please see below ...
no problem!
[aside: jeff, great advice on tps determination]
> >> fsync = on # turns forced synchronization
> > have you tried turning this off and measuring performance?
>
> No, not yet. We're trying a couple of outher avenues before manipulating
> this parameter.
ok. just keep in mind that keeping fsync on keeps an aboslute upper
limit on your tps that is largely driven by hardware. with a raid
controller write caching controller caching writes the penalty is
extremely low but without write caching you might get ~150 tps on a
relatively high end raid system. moreover, your disks are totally
utilized providing those 150 tps. (transactions with writing, that
is)
symptoms of sync bottleneck are little/no cpu utilization, sustained
high iowait, and extremely poor performance and an unresponsive
server. the best solution to sync issues is to have a
hardware/software strategy designed to deal with it.
if you are having periodic performance issues, you might be having
checkpoint storms. Thse are controllable by tuning the wal and
especially the bgwriter. These are easy to spot: you can do manual
checkpoints in psql and closely monitor the load.
> We've reduced the load significantly primarily by moving pg_xlog to its
> own drive and by increasing the effective cache size. While we still see
> high load levels, they don't last very long. We're trying improve
> performance from several angles but are taking it one step at a time.
> Eventually we'll experiment with fsynch
good!
merlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mmoncure@gmail.com, andy.rost@noaa.gov, Bill.Sites@noaa.gov, jeff@frostconsultingllc.com
Subject: Re: Opteron/FreeBSD/PostgreSQL performance poor
In-Reply-To: <b42b73150607090747i27a282b6u6c1fda4efcb2f3fe@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox