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 21:22:47
Message-ID: dlisba$fpf$1@news.hub.org (view raw or flat)
Thread:
Lists: pgsql-performance
Joshua Marsh wrote:
> 
> On 11/17/05, *William Yu* <wyu(at)talisys(dot)com <mailto:wyu(at)talisys(dot)com>> wrote:
> 
>      > 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".
> 
> 
> We all want our systems to be CPU bound, but it's not always possible.  
> Remember, he is managing a 5 TB Databse.  That's quite a bit different 
> than a 100 GB or even 500 GB database.

I did say "in theory". :) I'm pretty sure google is more CPU bound than 
IO bound -- they just spread their DB over 50K servers or whatever. Not 
everybody is willing to pay for that but it's always in the realm of 
plausibility.

Plus we have to go back to the statement I was replying to which was "I 
have yet to come across a DB system that wasn't IO bound".


In response to

pgsql-performance by date

Next:From: Andrew SullivanDate: 2005-11-17 22:13:14
Subject: Re: weird performances problem
Previous:From: Craig A. JamesDate: 2005-11-17 21:04:21
Subject: Re: Perl DBD and an alarming problem

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