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
pgsql-performance by date
|Next:||From: Marc Mamin||Date: 2010-12-11 10:27:59|
|Subject: Re: UNION and bad performance|
|Previous:||From: Greg Smith||Date: 2010-12-11 09:10:45|
|Subject: Re: Hardware recommendations|