| From: | Kenneth Marshall <ktm(at)rice(dot)edu> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Craig James <craig_james(at)emolecules(dot)com>, Whit Armstrong <armstrong(dot)whit(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: partition question for new server setup |
| Date: | 2009-04-28 18:40:41 |
| Message-ID: | 20090428184041.GK26100@it.is.rice.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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.
Cheers,
Ken
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2009-04-28 19:13:12 | Re: partition question for new server setup |
| Previous Message | Whit Armstrong | 2009-04-28 18:37:37 | Re: partition question for new server setup |