Re: How to improve db performance with $7K?

The Linux kernel is definitely headed this way. The 2.6 allows for
several different I/O scheduling algorithms. A brief overview about the
different modes:

http://nwc.serverpipeline.com/highend/60400768

Although a much older article from the beta-2.5 days, more indepth info
from one of the programmers who developed the AS scheduler and worked on
the deadline scheduler:

http://kerneltrap.org/node/657

I think I'm going to start testing the deadline scheduler for our data
processing server for a few weeks before trying it on our production
servers.




Alex Turner wrote:
> Whilst I admire your purist approach, I would say that if it is
> beneficial to performance that a kernel understand drive geometry,
> then it is worth investigating teaching it how to deal with that!
>
> I was less referrring to the kernel as I was to the controller.
>
> Lets say we invented a new protocol that including the drive telling
> the controller how it was layed out at initialization time so that the
> controller could make better decisions about re-ordering seeks.  It
> would be more cost effective to have that set of electronics just once
> in the controller, than 8 times on each drive in an array, which would
> yield better performance to cost ratio.  Therefore I would suggest it
> is something that should be investigated.  After all, why implemented
> TCQ on each drive, if it can be handled more effeciently at the other
> end by the controller for less money?!
>
> Alex Turner
> netEconomist
>
> On 4/19/05, Dave Held <dave.held@arrayservicesgrp.com> wrote:
>
>>>-----Original Message-----
>>>From: Alex Turner [mailto:armtuk@gmail.com]
>>>Sent: Monday, April 18, 2005 5:50 PM
>>>To: Bruce Momjian
>>>Cc: Kevin Brown; pgsql-performance@postgresql.org
>>>Subject: Re: [PERFORM] How to improve db performance with $7K?
>>>
>>>Does it really matter at which end of the cable the queueing is done
>>>(Assuming both ends know as much about drive geometry etc..)?
>>>[...]
>>
>>The parenthetical is an assumption I'd rather not make.  If my
>>performance depends on my kernel knowing how my drive is laid
>>out, I would always be wondering if a new drive is going to
>>break any of the kernel's geometry assumptions.  Drive geometry
>>doesn't seem like a kernel's business any more than a kernel
>>should be able to decode the ccd signal of an optical mouse.
>>The kernel should queue requests at a level of abstraction that
>>doesn't depend on intimate knowledge of drive geometry, and the
>>drive should queue requests on the concrete level where geometry
>>matters.  A drive shouldn't guess whether a process is trying to
>>read a file sequentially, and a kernel shouldn't guess whether
>>sector 30 is contiguous with sector 31 or not.
>>
>>__
>>David B. Held
>>Software Engineer/Array Services Group
>>200 14th Ave. East,  Sartell, MN 56377
>>320.534.3637 320.253.7800 800.752.8129
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 7: don't forget to increase your free space map settings
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>