<jason.servetar@ccgenesis.com> writes:
> Currently we are running a dual cpu dell blade server on redhat linux
> (2.4?) and PostgreSQL 7.3.4 on i686-pc-linux-gnu, compiled by GCC 2.96,
> raid5 and am using sqlrelay for connection pooling. It works fine under
> ordinary load but bogs down too much under these huge loads.
I can't answer the question you asked. But I would suggest you upgrade your
compiler. 2.96 is just about the worst version of gcc to be using for
anything. It has known bugs where it just flatly miscompiles code, resulting
in programs that crash or behave strangely.
Also postgresql 7.4 has lots of very nice performance improvements including
everyone's favourite, "IN" optimization. So you might consider upgrading to
7.4.2.
> I would love to be able to tell them that a specific box like a 2 ghz
> quad xenon with 10 GB of ram, on a raid 10 server will get them x
> concurrent transactions per second with x threads running. From that I
> can give them a great estimate on how many registrations per minute
> there money can buy, but right now all I can tell them is that if you
> spend more money you will get more tps.
Unfortunately nobody will be able to give you precise numbers since it will
depend a *lot* on the precise queries and database design you're working with.
There are also a lot of variables in the hardware design where you trade off
increasing cpus vs improving the disk subsystem and such.
You're going to have to do some performance testing of your application on
different hardware and extrapolate from that. Unfortunately (or fortunately
depending on your billing model:) this can be a lot of work. It involves
setting up a database with a realistic quantity of data, and some sort of test
harness simulating users.
In general terms though, several people have mentioned being happy with
Opteron servers, and generally people find spending money on good hardware
RAID cards with battery backed caches and more disks to spread data over to be
more effective than spending money on more or faster processors.
If you benchmark your application on a given set of hardware and analyze where
your bottleneck is then people may be able to suggest what alternatives to
consider and may be able to give some idea of what type of improvement to
expect. But it takes actual data from vmstat, iostat, et al to do this
analysis.
--
greg
