Re: Server Hardware Configuration - Mailing list pgsql-admin

I'd advise staying far away from RAID5 -- the link below is one frequently pointed to in Informix discussions, but I
thinkthe points apply to any RDBMS. If you value your data (and sanity) stay with a more reliable setup -- performance
isnot the only problem with RAID5. 

<http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt>

In general, lots of spindles and lots of RAM seems to reduce the pain of large data sets (our larger servers have about
15-18gigs), but we're not doing a lot of OLTP, so our setup might not be similar to what you need. 

Greg Williamson
DBA
GlobeXplorer LLC

-----Original Message-----
From:    pgsql-admin-owner@postgresql.org on behalf of Jim C. Nasby
Sent:    Sun 11/20/2005 9:53 AM
To:    Michael D. Sofka
Cc:    pgsql-admin@postgresql.org
Subject:    Re: [ADMIN] Server Hardware Configuration
Two general comments: most people find that Opterons perform much better
than Xeons. With some versions of PostgreSQL, the difference is over
50%.

RAID5 generally doesn't make for a fast database. The problem is that
there is a huge amount of overhead everytime you go to write something
out to a RAID5 array. With careful tuning of the background writer you
might be able to avoid some of that penalty, though your read
performance will likely still be affected by the write overhead.

BTW, -performance is a better list for info about this. If you look in
the archives you'll be able to read a lot of threads from people seeking
hardware advice.

On Thu, Nov 17, 2005 at 09:54:38AM -0500, Michael D. Sofka wrote:
> We are running PostgreSQL as the back-end to a spam scanning system.  The
> database holds suspected spam, and user configuration information.  A
> web interface allows people to accept, or (usually) discard the trapped
> messages.   So, most data is write once, read at most once, delete.
>
> The total size of the db is about 16gig in size.  And, we expect it
> could grow to 4 times this as more users are opted into spam scanning.
> During most of the day, the machine is only lightly loaded.  There are
> two bursts of activity: the nightly vacuum, and the first thing in the
> morning spam checking.
>
> Our current db machine has two hyper-threaded 2.4 GHz Xeon processors, 4
> gig of main memory, and is attached to a JBOD configured with RAID 5 for
> the database, and mirrored disks for the DB logs.
>
> It is time to upgrade the machine.   Two possibilities present themselves.
>
>    1.  PowerEdge 6850
>        4 3.16 GHz Xeon processors
>        16 gig of memory
>        Internal RAID 5 (only 3 disks)
>        2 Mirrored disks for root and db log.
>
>    2.  PowerEdge 2850
>        2 Dual core 2.8GHz Xeon processors
>        8 gig of memory
>        JBOD with RAID 5, and mirrored db log.
>
> Both configurations will cost about the same, within $\Delta$ for an
> acceptable value of $\Delta$.  The idea behind the first is to keep the
> entire database in memory, by way of the disk cache.  Alas, to keep it
> affordable (The extra memory is expensive) the JBOD must be jettisoned.
> The second is a larger version of our current configuration.  (The 6850
> with a JBOD would stretch the budget beyond $\Delta$, and the expense
> would be difficult to justify.)
>
> I'm looking for any comments, or suggestions.  With expected growth, the
> first configuration seems out of balance---it will likely start off
> fast, but with growth the slower disk configuration will likely be a
> problem.  Is anybody running PostgreSQL in a large memory, slower disk
> configuration?  What are your experiences.
>
> Thank You,
>
> Mike
>
> P.S. We are investigating if the current IBM JBOD will work with the
> Dell PERC cards.  But, even if they do, the current JBOD is populated
> with soon to be extended warranty disks, and so progressively costly.
>
> --
> Michael D. Sofka              sofkam@rpi.edu
> C&CT Sr. Systems Programmer    Email, TeX, epistemology.
> Rensselaer Polytechnic Institute, Troy, NY.  http://www.rpi.edu/~sofkam/
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

!DSPAM:4380b2ea101321248155993!