<[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly