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

Re: 8.4.1 ubuntu karmic slow createdb

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>
Cc: Nikolas Everett <nik9000(at)gmail(dot)com>, jd <jd(at)commandprompt(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>, Michael Clemmons <glassresistor(at)gmail(dot)com>
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Date: 2009-12-11 22:39:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
Scott Mead wrote:
> The other common issue is that developers running with something like 
> 'fsync=off' means that they have completely unrealistic expectations 
> of the performance surrounding something.
Right, but the flip side here is that often the production server will 
have hardware such as a caching RAID card that vastly improves 
performance in this area.  There's some room to cheat in order to 
accelerate the dev systems lack of such things, while still not giving a 
completely unrealistic view of performance.

As far as I'm concerned, using "fsync=off" is almost never excusable if 
you're running 8.3 or later where "synchronous_commit=off" is a 
possibility.  If you use that, it will usually improve the worst part of 
commit issues substantially.  And it happens in a way that's actually 
quite similar to how a caching write production server will run:  small 
writes happen instantly, but eventually bigger ones will end up 
bottlenecked at the disks anyway.

It would improve the average safety of our community members if anytime 
someone suggests "fsync=off", we strongly suggest 
"synchronous_commit=off" and potentially tuning its interval instead as 
a middle ground, while still helping people who need to speed their 
systems up.  Saying "never turn fsync off" without suggesting this 
alternative is counter-productive.  If you're in the sort of position 
where fsync is killing your performance you'll do anything to speed 
things up (I've seen a 100:1 speed improvement) no matter how risky.  
I've ran a production system of 8.2 with fsync off, a TB of data, and no 
safety net if a crash introduced corruption beyond a ZFS snapshot.  It 
wasn't fun, but it was the only possibility to get bulk loading (there 
was an ETL step in the middle after COPY) to happen fast enough.  Using 
async commit instead is a much better approach now that it's available.

Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support

In response to


pgsql-performance by date

Next:From: Michael ClemmonsDate: 2009-12-11 22:52:01
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Previous:From: Scott MarloweDate: 2009-12-11 22:19:05
Subject: Re: 8.4.1 ubuntu karmic slow createdb

pgsql-hackers by date

Next:From: Michael ClemmonsDate: 2009-12-11 22:52:01
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Previous:From: Stephen FrostDate: 2009-12-11 22:36:54
Subject: Re: Adding support for SE-Linux security

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