X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id AFD90DB84A for ; Wed, 16 Nov 2005 08:51:54 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 99991-05 for ; Wed, 16 Nov 2005 12:51:56 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by svr1.postgresql.org (Postfix) with ESMTP id A10DADAB5A for ; Wed, 16 Nov 2005 08:51:50 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id A1D6531058; Wed, 16 Nov 2005 13:51:53 +0100 (MET) From: William Yu X-Newsgroups: pgsql.performance Subject: Re: Hardware/OS recommendations for large databases ( Date: Wed, 16 Nov 2005 04:51:49 -0800 Organization: Hub.Org Networking Services Lines: 20 Message-ID: References: <3E37B936B592014B978C4415F90D662D01995F7B@MI8NYCMAIL06.Mi8.com> <33c6269f0511152116s4483af82s91c711b1b902da14@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en In-Reply-To: <33c6269f0511152116s4483af82s91c711b1b902da14@mail.gmail.com> To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[AWL=0.000] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200511/269 X-Sequence-Number: 15526 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.