From: Greg Smith <gsmith@gregsmith.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Craig Ringer <craig@postnewspapers.com.au>
Cc: Peter Schuller <peter.schuller@infidyne.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Identifying the nature of blocking I/O
Date: Thu, 28 Aug 2008 23:53:39 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0808282324360.11207@westnet.com> (raw)
In-Reply-To: <866.1219628227@sss.pgh.pa.us>
References: <20080822115243.GA10981@hyperion.scode.org>
<48B1FD1A.7040807@postnewspapers.com.au>
<866.1219628227@sss.pgh.pa.us>
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@gregsmith.com http://www.gregsmith.com Baltimore, MD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: gsmith@gregsmith.com, tgl@sss.pgh.pa.us, craig@postnewspapers.com.au, peter.schuller@infidyne.com
Subject: Re: Identifying the nature of blocking I/O
In-Reply-To: <Pine.GSO.4.64.0808282324360.11207@westnet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox