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

Re: partition question for new server setup

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Kenneth Marshall <ktm(at)rice(dot)edu>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Craig James <craig_james(at)emolecules(dot)com>, Whit Armstrong <armstrong(dot)whit(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: partition question for new server setup
Date: 2009-04-28 19:19:36
Message-ID: dcc563d10904281219j33d6b7adyed322a3e6add8b02@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, Apr 28, 2009 at 12:40 PM, Kenneth Marshall <ktm(at)rice(dot)edu> wrote:
> On Tue, Apr 28, 2009 at 01:30:59PM -0500, Kevin Grittner wrote:
>> Craig James <craig_james(at)emolecules(dot)com> wrote:
>>
>> > After a reading various articles, I thought that "noop" was the
>> > right choice when you're using a battery-backed RAID controller.
>> > The RAID controller is going to cache all data and reschedule the
>> > writes anyway, so the kernal schedule is irrelevant at best, and can
>> > slow things down.
>>
>> Wouldn't that depend on the relative sizes of those caches?  In a
>> not-so-hypothetical example, we have machines with 120 GB OS cache,
>> and 256 MB BBU RAID controller cache.  We seem to benefit from
>> elevator=deadline at the OS level.
>>
>> -Kevin
>>
> This was my understanding as well. If your RAID controller had a
> lot of well managed cache, then the noop scheduler was a win. Less
> performant RAID controllers benefit from teh deadline scheduler.

I have an Areca 1680ix with 512M cache on a machine with 32Gig ram and
I get slightly better performance and lower load factors from deadline
than from noop, but it's not by much.

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2009-04-28 21:41:21
Subject: Re: pg_lock_status() performance
Previous:From: Scott MarloweDate: 2009-04-28 19:17:54
Subject: Re: partition question for new server setup

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