Re: how to configure my new server

Hello @ all,

Josh wrote:
>> With a large database you may even think about
>> shifting individual tables or indexes to seperate disks.

OK, I admit it was a bit provoking. It was my intention to stir things up a little bit ;-) IMHO, thinking about locating data on dedicated files is a waste of time on small servers. Let the hardware do the job for you! It is "good enough".

Eric wrote:
>>Unfortunately, today's hardware still has rotational latency. You aren't goign to get much
>> more than 300 seeks per sec on the best single drive. Putting them together in a way that
>> requires half to all of them to seek for a given read or write is a performance killer.
>> The only way around this is high end raid cards with backup batteries and ram.

You're right, 300 seeks is best you can expect from a state-of-the-art HD. But the average disk request will certainly not be performed over several disks. Usual block size for RAID is 32kb or 64kb, while most requests will be only some kb (assuming you're not doing full table scans all the time). Thus, the usual request will require only one disk to be accessed on read. This way, a 10-disk array will be capable of up to 3000 requests/second (if the controller allows this).

Actually, I don't trust software RAID. If I'm talking about RAID, I mean mature RAID solutions, using SCSI or similar professional equipment. More RAM, ideally with backup power, is desirable. For small servers, a RAID controller < 1000 $ usually will do. IDE RAID, uhm eh... I never did like it, and I doubt that IDE RAID controller are doing a good job optimizing for this kind of traffic. IMHO, they are meant for workstation, leave them there. And remember, if we talk about access time, typical latency for a SCSI disk is half of fast IDE disks, giving double speed for typical DB access patterns. You may use IDE if speed means MB/s, but for us it's seeks/s.

I don't think solid state disks are a way out (unless you don't know where to bury your money :-). Maybe the gurus can tell more about PostgreSQL's caching, but for my opinion if enough RAM is available after some time all of the DB should be in cache eliminating the need to access the disks for read access. For writing, which is typically less than 10 % of total load, an optimizing caching disk controller should be sufficient.

Andreas