From: Scott Carey <scott@richrelevance.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: jd@commandprompt.com <jd@commandprompt.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Jean-David Beyer <jeandavid8@verizon.net>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Need help with 8.4 Performance Testing
Date: Tue, 9 Dec 2008 21:48:02 -0800
Message-ID: <C5649812.FC6%scott@richrelevance.com> (raw)
In-Reply-To: <603c8f070812091906j2f164215v91c907f8bff8e440@mail.gmail.com>
Just to clarify, I'm not talking about random I/O bound loads today, on hard drives, targetted by the fadvise stuff - these aren't CPU bound, and they will be helped by it.
For sequential scans, this situation is different, since the OS has sufficient read-ahead prefetching algorithms of its own for sequential reads, and the CPU work and I/O work ends up happening in parallel due to that.
For what it is worth, you can roughly double to triple the iops of an Intel X-25M on pure random reads if you queue up multiple concurrent reads rather than serialize them. But it is not due to spindles, it is due to the latency of the SATA interface and the ability of the controller chip to issue reads to flash devices on different banks concurrently to some extent.
On 12/9/08 7:06 PM, "Robert Haas" <robertmhaas@gmail.com> wrote:
> Well, when select count(1) reads pages slower than my disk, its 16x + slower
> than my RAM. Until one can demonstrate that the system can even read pages
> in RAM faster than what disks will do next year, it doesn't matter much that
> RAM is faster. It does matter that RAM is faster for sorts, hashes, and
> other operations, but at the current time it does not for the raw pages
> themselves, from what I can measure.
>
> This is in fact, central to my point. Things will be CPU bound, not I/O
> bound. It is mentioned that we still have to access things over the bus,
> and memory is faster, etc. But Postgres is too CPU bound on page access to
> take advantage of the fact that memory is faster (for reading data pages).
As I understand it, a big part of the reason for the posix_fadvise
patch is that the current system doesn't do a good job leveraging many
spindles in the service of a single query. So the problem is not that
the CPU overhead is too large in some general sense but that the disk
and CPU operations get serialized, leading to an overall loss of
performance. On the other hand, there are certainly cases (such as a
database which is entirely in RAM, or all the commonly used parts are
in RAM) where there really isn't very much I/O, and in those cases of
course the CPU cost will dominate.
...Robert
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: scott@richrelevance.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, jd@commandprompt.com, mmoncure@gmail.com, scott.marlowe@gmail.com, jeandavid8@verizon.net
Subject: Re: Need help with 8.4 Performance Testing
In-Reply-To: <C5649812.FC6%scott@richrelevance.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