--On Saturday, November 19, 2005 12:15:46 AM +0000 John Jensen <jrj@xxxxx>
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@xxxxxxxxxxxxx> 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@xxxxxxx
C&CT Sr. Systems Programmer Email, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
