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@xxxxxxxxxxxxxxx Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
