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

> -----Original Message-----
> From: Alex Turner [mailto:armtuk(at)gmail(dot)com]
> Sent: Monday, April 18, 2005 5:50 PM
> To: Bruce Momjian
> Cc: Kevin Brown; pgsql-performance(at)postgresql(dot)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

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(dot)held(at)arrayservicesgrp(dot)com> wrote:
> > -----Original Message-----
> > From: Alex Turner [mailto:armtuk(at)gmail(dot)com]
> > Sent: Monday, April 18, 2005 5:50 PM
> > To: Bruce Momjian
> > Cc: Kevin Brown; pgsql-performance(at)postgresql(dot)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
>

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(dot)held(at)arrayservicesgrp(dot)com> wrote:
>
>>>-----Original Message-----
>>>From: Alex Turner [mailto:armtuk(at)gmail(dot)com]
>>>Sent: Monday, April 18, 2005 5:50 PM
>>>To: Bruce Momjian
>>>Cc: Kevin Brown; pgsql-performance(at)postgresql(dot)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
>