We are running PostgreSQL as the back-end to a spam scanning system. The
database holds suspected spam, and user configuration information. A
web interface allows people to accept, or (usually) discard the trapped
messages. So, most data is write once, read at most once, delete.
The total size of the db is about 16gig in size. And, we expect it
could grow to 4 times this as more users are opted into spam scanning.
During most of the day, the machine is only lightly loaded. There are
two bursts of activity: the nightly vacuum, and the first thing in the
morning spam checking.
Our current db machine has two hyper-threaded 2.4 GHz Xeon processors, 4
gig of main memory, and is attached to a JBOD configured with RAID 5 for
the database, and mirrored disks for the DB logs.
It is time to upgrade the machine. Two possibilities present themselves.
1. PowerEdge 6850
4 3.16 GHz Xeon processors
16 gig of memory
Internal RAID 5 (only 3 disks)
2 Mirrored disks for root and db log.
2. PowerEdge 2850
2 Dual core 2.8GHz Xeon processors
8 gig of memory
JBOD with RAID 5, and mirrored db log.
Both configurations will cost about the same, within $\Delta$ for an
acceptable value of $\Delta$. The idea behind the first is to keep the
entire database in memory, by way of the disk cache. Alas, to keep it
affordable (The extra memory is expensive) the JBOD must be jettisoned.
The second is a larger version of our current configuration. (The 6850
with a JBOD would stretch the budget beyond $\Delta$, and the expense
would be difficult to justify.)
I'm looking for any comments, or suggestions. With expected growth, the
first configuration seems out of balance---it will likely start off
fast, but with growth the slower disk configuration will likely be a
problem. Is anybody running PostgreSQL in a large memory, slower disk
configuration? What are your experiences.
P.S. We are investigating if the current IBM JBOD will work with the
Dell PERC cards. But, even if they do, the current JBOD is populated
with soon to be extended warranty disks, and so progressively costly.
Michael D. Sofka sofkam(at)rpi(dot)edu
C&CT Sr. Systems Programmer Email, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
pgsql-admin by date
|Next:||From: Colton A Smith||Date: 2005-11-17 14:55:44|
|Subject: COPY and partitioning|
|Previous:||From: Qingqing Zhou||Date: 2005-11-17 14:10:08|
|Subject: Re: [ADMIN] ERROR: could not read block|