Re: Server Hardware Configuration - Mailing list pgsql-admin

From Michael D. Sofka
Subject Re: Server Hardware Configuration
Date
Msg-id CD54090BD5C5F87C1B2A7F3C@betelgeuse.cct.rpi.edu
Whole thread Raw
In response to Server Hardware Configuration  ("Michael D. Sofka" <sofkam@rpi.edu>)
Responses Re: Server Hardware Configuration
List pgsql-admin
--On Saturday, November 19, 2005 12:15:46 AM +0000 John Jensen <jrj@ft.fo>
wrote:

> What you describe is a real-time system. Does your
> requirements call for real-time performance ?
> Remember that performance from memory is much more
> expensive than disk i/o (at least up to a certain point).

No, we are not RT.  This is a good point.  Stability, reliability, and
reasonable response time are what we require.  It stores spam. We don't
want to go to heroic efforts to save the spam in the event of failure.
(We've been there, and don't want to do it again. :-)

> This is not exactly an optimum case for caching. I would
> suggest thinking really hard before going for an all memory
> solution. From what you write I would suggest a firm focus
> on disc i/o.

...

> I suggest looking at your current bottleneck first.
> It's likely to be the most cost-efficient route out.

I/O is our bottleneck.  The machine is not CPU loaded.  And, in fact,
our current performance is good.  The machine upgrade is planned with a
service upgrade.  Current hardware is old, and so getting more expensive
to support.  We also anticipate service growth (read, more spam), and
so are planning accordingly.

> Good luck in your quest for "bang per buck" ;-)

Thank You,

--On Sunday, November 20, 2005 11:53:37 AM -0600 "Jim C. Nasby"
<jnasby@pervasive.com> wrote:

> Two general comments: most people find that Opterons perform much better
> than Xeons. With some versions of PostgreSQL, the difference is over
> 50%.

Interesting.  Alas, Opteron is not a choice. :-(

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

We've had experience with RAID 5, and RAID 1+0 on various servers.  We
always use RAID with battery backed RAM, which greatly improves RAID 5
performance.  RAID 1+0 is always faster, but cost is always an issue.

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

Thank you, I'll look there.

Mike

--
Michael D. Sofka              sofkam@rpi.edu
C&CT Sr. Systems Programmer    Email, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY.  http://www.rpi.edu/~sofkam/


pgsql-admin by date:

Previous
From:
Date:
Subject: Batch Files
Next
From: Nirmal Kumar
Date:
Subject: Postgres Database slow