Re: Performance advice for a new low(er)-power server

From: Haestan <haestan(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance advice for a new low(er)-power server
Date: 2011-06-17 09:13:32
Message-ID: EEC749F3-1859-4FC7-8CA4-81404003EE45@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On Jun 16, 2011, at 20:43, Greg Smith wrote:
> The layout you proposed (OS+WAL , data) might be effective, but if your write volume is low it may not be much of an improvement at all over a simple RAID1 of two drives. The odds that you are going to correctly lay out individual sections of a disk array with only two pairs to spread the data across aren't good. If this is all you have to work with, a 4-disk RAID10 would at least guarantee you're taking advantage of all four drives. With that controller, it should be almost twice as fast in all cases as hooking up only two drives.

The data is more or less constantly rewritten (it contains hourly updated travel related data). Therefore, I really tend to buy 4 disks from the start on.

> There is another possibility I would suggest you consider. You could buy the server with a single pair of drives now, then wait to see what performance is like before filling the other two slots. It is far easier to figure out what drive technology makes sense if you have measurements from an existing system to guide that decision. And you may be able to get newer drives from your vendor that slide into the empty slots. You may not ever even need more than a single RAID-1 pair. I see lots of people waste money on drives that would be better spent on RAM.

Actually, there are already two older servers in place right now. The data is about 14GB in size and slowly rising. Considering the price for RAM I can easily afford to install more RAM than the db data is in size. I was aiming for 24GB. But even then, I cannot be sure that no queries will read from the disk. AFAIK, there is no way to force all the data to stay in cache (shared_buffers for example).

Thank you for your input so far.

Regards,

Tom.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message jesper 2011-06-17 09:30:33 Re: Performance advice for a new low(er)-power server
Previous Message Haestan 2011-06-17 08:42:19 Re: Performance advice for a new low(er)-power server