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

Re: Hardware recommendations

From: "Benjamin Krajmalnik" <kraj(at)servoyant(dot)com>
To: "Greg Smith" <greg(at)2ndquadrant(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Hardware recommendations
Date: 2010-12-13 20:45:10
Message-ID: F4E6A2751A2823418A21D4A160B689887B0AE5@fletch.stackdump.local (view raw, whole thread or download thread mbox)
Lists: pgsql-performance

> -----Original Message-----
> From: Greg Smith [mailto:greg(at)2ndquadrant(dot)com]
> Sent: Saturday, December 11, 2010 2:18 AM
> To: Benjamin Krajmalnik
> Cc: pgsql-performance(at)postgresql(dot)org
> Subject: Re: [PERFORM] Hardware recommendations
> 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.

I did a vacuum full of the highly bloated, constantly accessed tables,
which has improved the situation significantly.  I am not seeing over
75% busy right now, but these are some values for the high busy

71%  344 w/s  7644 kw/s
81%  392 w/s  8880 kw/s
79%  393 w/s  9526 kw/s
75%  443 w/s  10245 kw/s
80%  436 w/s  10157 kw/s
76%  392 w/s  8438 kw/s

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

Yes, I have it configured at 1024 checkpoint_segments, 5min timeout,0.9
compiostat -x 5letion_target
> 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
> the range where you can mix them together and things should still be
> fine.

Thx.  I will place them in their own RAID1 (or mirror if I end up going
to ZFS)

> > 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
> 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.

Thx.  That was my overall plan - that's why I am opting for drives,
cache on the controller, and memory.

> --
> Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
> PostgreSQL Training, Services and Support
> "PostgreSQL 9.0 High Performance":

In response to


pgsql-performance by date

Next:From: Royce AusburnDate: 2010-12-13 21:03:54
Subject: Re: CPU bound
Previous:From: Josh BerkusDate: 2010-12-13 18:59:26
Subject: Re: CPU bound

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