Re: How to improve db performance with $7K? - Mailing list pgsql-performance
From | William Yu |
---|---|
Subject | Re: How to improve db performance with $7K? |
Date | |
Msg-id | d47c5l$1rjb$1@news.hub.org Whole thread Raw |
In response to | Re: How to improve db performance with $7K? (Alex Turner <armtuk@gmail.com>) |
List | pgsql-performance |
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 >
pgsql-performance by date: