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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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