Re: Major Linux performance regression; shouldn't we be worried about RHEL6?

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
Date: 2010-11-05 20:59:47
Message-ID: AANLkTinsRC9HQH2oemcsAvGn9ur=v-fdO05nLe=qJUvb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Nov 5, 2010 at 2:32 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> Why would it be off limits?  Is it likely to lose data due to power failure etc?
>
> If fsyncs are taking 5X as long, people can't use PostgreSQL on that
> platform.

I was under the impression that from 2.6.28 through 2.6.31 or so that
the linux kernel just forgot how to fsync, and they turned it back on
in 2.6.32 and that's why we saw the big slowdown. Dropping from
thousands of transactions per second to 150 to 175 seems a reasonable
change when that happens.

>> Are you referring to improvements due to write barrier support getting
>> fixed up fr ext4 to run faster but still be safe?  I would assume that
>> any major patches that increase performance with write barriers
>> without being dangerous for your data would get back ported by RH as
>> usual.
>
> Hopefully, yes.  I wouldn't mind confirmation of this, though; it
> wouldn't be the first time RH shipped with known-bad IO performance.

true, very true. I will say that with my 2.6.32 based Ubuntu 10.04.1
LTS servers, running pgsql on an LSI 8888 controller can pull off 7500
tps quite easily. And quite safely, having survived power off tests
quite well. That's on ext3 though. I haven't tested them with ext4,
as when I set them up I still didn't consider it stable enough for
production.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2010-11-05 21:10:36 Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
Previous Message Greg Smith 2010-11-05 20:58:36 Re: Bufer cache replacement LRU algorithm?