Skip site navigation (1) Skip section navigation (2)

Re: Hardware recommendations

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Benjamin Krajmalnik <kraj(at)servoyant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Hardware recommendations
Date: 2010-12-11 09:18:12
Message-ID: 4D0341D4.9000207@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-performance
Benjamin Krajmalnik wrote:
> I am already having serious I/O bottlenecks with iostat -x showing extended periods where the disk subsystem on the data partition (the one with all the random i/o) at over 85% busy.  The system is running FreeBSD 7.2 amd64 and PostgreSQL 8.4.4 on amd64-portbld-freebsd7.2, compiled by GCC cc (GCC) 4.2.1 20070719  [FreeBSD], 64-bit.
> Currently I have about 4GB of shared memory allocated to PostgreSQL.  Database is currently about 80GB, with about 60GB being in partitioned tables which get rotated nightly to purge old data (sort of like a circular buffer of historic data).
>   

What sort of total read/write rates are you seeing when iostat is 
showing the system 85% busy?  That's a useful number to note as an 
estimate of just how random the workload is.

Have you increased checkpoint parameters like checkpoint_segments?  You 
need to avoid having checkpoints too often if you're going to try and 
use 4GB of memory for shared_buffers.

> I was looking at one of the machines which Aberdeen has (the X438), and was planning  on something along the lines of 96GB RAM with 16 SAS drives (15K).  If I create a RAID 10 (stripe of mirrors), leaving 2 hot spares, should I still place the logs in a separate RAID-1 mirror, or can they be left on the same RAID-10 container?
>   

It's nice to put the logs onto a separate disk because it lets you 
measure exactly how much I/O is going to them, relative to the 
database.  It's not really necessary though; with 14 disks you'll be at 
the range where you can mix them together and things should still be fine.


> On the processor front, are there advantages to going to X series processors as opposed to the E series (especially since I am I/O bound)?  Is anyone running this type of hardware, specially on FreeBSD?  Any opinions, especially concerning the Areca controllers which they use?
>   

It sounds like you should be saving your hardware dollars for more RAM 
and disks, not getting faster procesors.  The Areca controllers are fast 
and pretty reliable under Linux.  I'm not aware of anyone using them for 
PostgreSQL in production on FreeBSD.  Aberdeen may have enough customers 
doing that to give you a good opinion on how stable that is likely to 
be; they're pretty straight as vendors go.  You'd want to make sure to 
stress test that hardware/software combo as early as possible 
regardless, it's generally a good idea and you wouldn't be running a 
really popular combination.

-- 
Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


In response to

Responses

pgsql-performance by date

Next:From: Marc MaminDate: 2010-12-11 10:27:59
Subject: Re: UNION and bad performance
Previous:From: Greg SmithDate: 2010-12-11 09:10:45
Subject: Re: Hardware recommendations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group