From: William Yu <wyu@talisys.com>
To: pgsql-performance@postgresql.org
Subject: Re: Hardware/OS recommendations for large databases (
Date: Wed, 16 Nov 2005 04:51:49 -0800
Message-ID: <dlfa10$2b2n$1@news.hub.org> (raw)
In-Reply-To: <33c6269f0511152116s4483af82s91c711b1b902da14@mail.gmail.com>
References: <3E37B936B592014B978C4415F90D662D01995F7B@MI8NYCMAIL06.Mi8.com>
<B41A9E46-AC4F-4A3A-B383-AB70091745CF@fastcrypt.com>
<33c6269f0511152116s4483af82s91c711b1b902da14@mail.gmail.com>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: wyu@talisys.com
Subject: Re: Hardware/OS recommendations for large databases (
In-Reply-To: <dlfa10$2b2n$1@news.hub.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox