Re: Maximum transaction rate

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jack Orenstein <jack(dot)orenstein(at)hds(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Maximum transaction rate
Date: 2009-03-16 20:03:01
Message-ID: 49BEB075.6000400@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> Jack Orenstein <jack(dot)orenstein(at)hds(dot)com> writes:
>> The transaction rates I'm getting seem way too high: 2800-2900 with
>> one thread, 5000-7000 with ten threads. I'm guessing that writes
>> aren't really reaching the disk. Can someone suggest how to figure out
>> where, below postgres, someone is lying about writes reaching the
>> disk?
>
> AFAIK there are two trouble sources in recent Linux machines: LVM and
> the disk drive itself. LVM is apparently broken by design --- it simply
> fails to pass fsync requests. If you're using it you have to stop.
> (Which sucks, because it's exactly the kind of thing DBAs tend to want.)
> Otherwise you need to reconfigure your drive to not cache writes.
> I forget the incantation for that but it's in the PG list archives.

hmm are you sure this is what is happening?
In my understanding LVM is not passing down barriers(generally - it
seems to do in some limited circumstances) which means in my
understanding it is not safe on any storage drive that has write cache
enabled. This seems to be the very same issue like linux had for ages
before ext3 got barrier support(not sure if even today all filesystems
do have that).
So in my understanding LVM is safe on disks that have write cache
disabled or "behave" as one (like a controller with a battery backed cache).
For storage with write caches it seems to be unsafe, even if the
filesystem supports barriers and it has them enabled (which I don't
think all have) which is basically what all of linux was not too long ago.

Stefan

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joachim Tranvåg 2009-03-16 20:19:40 (0x0000274D/10061) on Install
Previous Message Umar Farooq 2009-03-16 19:43:22 Fwd: PostgreSQL Memory Management