From: | Alex Stapleton <alexs(at)advfn(dot)com> |
---|---|
To: | William Yu <wyu(at)talisys(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Hardware/OS recommendations for large databases ( |
Date: | 2005-11-16 14:13:26 |
Message-ID: | 41AD9695-69AC-4677-AEBD-9D9E21BD8DCF@advfn.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 16 Nov 2005, at 12:51, William Yu wrote:
> Alex Turner wrote:
>
>> Not at random access in RAID 10 they aren't, and anyone with their
>> head screwed on right is using RAID 10. The 9500S will still beat
>> the
>> Areca cards at RAID 10 database access patern.
>>
>
> The max 256MB onboard for 3ware cards is disappointing though.
> While good enough for 95% of cases, there's that 5% that could use
> a gig or two of onboard ram for ultrafast updates. For example, I'm
> specing out an upgrade to our current data processing server.
> Instead of the traditional 6xFast-Server-HDs, we're gonna go for
> broke and do 32xConsumer-HDs. This will give us mega I/O bandwidth
> but we're vulnerable to random access since consumer-grade HDs
> don't have the RPMs or the queueing-smarts. This means we're very
> dependent on the controller using onboard RAM to do I/O scheduling.
> 256MB divided over 4/6/8 drives -- OK. 256MB divided over 32 drives
> -- ugh, the HD's buffers are bigger than the RAM alotted to it.
>
> At least this is how it seems it would work from thinking through
> all the factors. Unfortunately, I haven't found anybody else who
> has gone this route and reported their results so I guess we're the
> guinea pig.
>
Your going to have to factor in the increased failure rate in your
cost measurements, including any downtime or performance degradation
whilst rebuilding parts of your RAID array. It depends on how long
your planning for this system to be operational as well of course.
Pick two: Fast, cheap, reliable.
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Wampler | 2005-11-16 14:29:44 | Re: Hardware/OS recommendations for large databases ( |
Previous Message | Ron | 2005-11-16 13:58:56 | Re: Hardware/OS recommendations for large databases |