Re: Identifying the nature of blocking I/O

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Peter Schuller <peter(dot)schuller(at)infidyne(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Identifying the nature of blocking I/O
Date: 2008-08-29 03:53:39
Message-ID: Pine.GSO.4.64.0808282324360.11207@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sun, 24 Aug 2008, Tom Lane wrote:

> Mind you, I don't think Apple sells any hardware that would be really
> suitable for a big-ass database server.

If you have money to burn, you can get an XServe with up to 8 cores and
32GB of RAM, and get a card to connect it to a Fiber Channel disk array.
For only moderately large requirements, you can even get a card with 256MB
of battery-backed cache (rebranded LSI) to attach the 3 drives in the
chassis. None of these are very cost effective compared to servers like
the popular HP models people mention here regularly, but it is possible.

As for Systemtap on Linux, it might be possible that will accumulate
enough of a standard library to be usable by regular admins one day, but I
don't see any sign that's a priority for development. Right now what you
have to know in order to write useful scripts is so much more complicated
than DTrace, where there's all sorts of useful things you can script
trivially. I think a good part of DTrace's success comes from flattening
that learning curve. Take a look at the one-liners at
http://www.solarisinternals.com/wiki/index.php/DTraceToolkit and compare
them against http://sourceware.org/systemtap/examples/

That complexity works against the tool on so many levels. For example, I
can easily imagine selling even a paranoid admin on running a simple
DTrace script like the one-line examples. Whereas every Systemtap example
I've seen looks pretty scary at first, and I can't imagine a DBA in a
typical enterprise environment being able to convince their associated
admin team they're perfectly safe to run in production.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2008-08-29 04:31:23 Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
Previous Message david 2008-08-29 03:02:48 Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception