Skip site navigation (1) Skip section navigation (2)

Re: Hardware/OS recommendations for large databases (

From: William Yu <wyu(at)talisys(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Hardware/OS recommendations for large databases (
Date: 2005-11-17 20:38:11
Message-ID: dlipnh$902$1@news.hub.org (view raw or flat)
Thread:
Lists: pgsql-performance
Alex Turner wrote:
> Opteron 242 - $178.00
> Opteron 242 - $178.00
> Tyan S2882 - $377.50
> Total: $733.50
> 
> Opteron 265 - $719.00
> Tyan K8E - $169.00
> Total: $888.00

You're comparing the wrong CPUs. The 265 is the 2x of the 244 so you'll 
have to bump up the price more although not enough to make a difference.

Looks like the price of the 2X MBs have dropped since I last looked at 
it. Just a few months back, Tyan duals were $450-$500 which is what I 
was basing my "priced less" statement from.

> Tyan K8E - doesn't have any PCI-X, so it's also not apples to apples. 
> Infact I couldn't find a single CPU slot board that did, so you pretty
> much have to buy a dual CPU board to get PCI-X.

You can get single CPU boards w/ PCIe and use PCIe controller cards. 
Probably expensive right now because they're so bleeding-edge new but 
definitely on the downswing.

> a) OLTP - probably IO bound, large number of queries/sec updating info
> on _disks_, not requiring much CPU activity except to retrieve item
> infomration which is well indexed and normalized.

Not in my experience. I find on our OLTP servers, we run 98% in RAM and 
hence are 100% CPU-bound. Our DB is about 50GB in size now, servers run 
w/ 8GB of RAM. We were *very* CPU limited running 2x244. During busy 
hours of the day, our avg "user transaction" time were jumping from 
0.8sec to 1.3+sec. Did the 2x265 and now we're always in the 0.7sec to 
0.9sec range.

>>DC also gives you a better upgrade path. Let's say you do testing and
>>figure 2x246 is the right setup to handle the load. Well instead of
>>getting 2x1P, use the same 2P motherboard but only populate 1 CPU w/ a
>>DC/270. Now you have a server that can be upgraded to +80% more CPU by
>>popping in another DC/270 versus throwing out the entire thing to get a
>>4x1P setup.
> 
> 
> No argument there.  But it's pointless if you are IO bound.

Why would you just accept "we're IO bound, nothing we can do"? I'd do 
everything in my power to make my app go from IO bound to CPU bound -- 
whether by optimizing my code or buying more hardware. I can tell you if 
our OLTP servers were IO bound, it would run like crap. Instead of < 1 
sec, we'd be looking at 5-10 seconds per "user transaction" and our 
users would be screaming bloody murder.

In theory, you can always convert your IO bound DB to CPU bound by 
stuffing more and more RAM into your server. (Or partitioning the DB 
across multiple servers.) Whether it's cost effective depends on the DB 
and how much your users are paying you -- and that's a case-by-case 
analysis. Not a global statement of "IO-bound, pointless".

>>(2) Does a DC system perform better than it's Nx1P cousin? My experience
>>is yes. Did some rough tests in a drop-in-replacement 1x265 versus 2x244
>>and saw about +10% for DC. All the official benchmarks (Spec, Java, SAP,
>>etc) from AMD/Sun/HP/IBM show DCs outperforming the Nx1P setups.
> 
> 
> Maybe true, but the 265 does have a 25% faster FSB than the 244, which
> might perhaps play a role.

Nope. There's no such thing as FSB on Opterons. On-die memory controller 
runs @ CPU speed and hence connects at whatever the memory runs at 
(rounded off to some multiplier math). There's the HT speed that 
controls the max IO bandwidth but that's based on the motherboard, not 
the CPU. Plus the 265 and 244 both run at 1.8Ghz so the memory 
multiplier & HT IO are both the same.

In response to

Responses

pgsql-performance by date

Next:From: Joshua D. DrakeDate: 2005-11-17 20:39:55
Subject: Re: Hardware/OS recommendations for large databases (
Previous:From: Josel MalixiDate: 2005-11-17 20:34:16
Subject: unsubscribe

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group