From: Zoltan Boszormenyi <zb@cybertec.at>
To: Greg Smith <gsmith@gregsmith.com>
Cc: Hans-Juergen Schoenig <postgres@cybertec.at>
Cc: pgsql-patches <pgsql-patches@postgresql.org>
Subject: Re: posix advises ...
Date: Fri, 20 Jun 2008 12:24:13 +0200
Message-ID: <485B854D.1050200@cybertec.at> (raw)
In-Reply-To: <Pine.GSO.4.64.0806191900400.15572@westnet.com>
References: <4826C200.8060807@cybertec.at>
<Pine.GSO.4.64.0805132139250.20823@westnet.com>
<485A3F20.1080907@cybertec.at>
<Pine.GSO.4.64.0806191900400.15572@westnet.com>
Greg Smith írta:
> On Thu, 19 Jun 2008, Zoltan Boszormenyi wrote:
>
>> This patch (revisited and ported to current CVS HEAD) is indeed using
>> Greg's original patch and also added another patch written by Mark Wong
>> that helps evicting closed XLOGs from memory faster.
>
> Great, that will save me some trouble. I've got a stack of Linux
> performance testing queued up (got stuck behind a kernel bug impacting
> pgbench) for the next couple of weeks and I'll include this in that
> testing. I think I've got a similar class of hardware as you tested
> on for initial evaluation--I'm getting around 200MB/s sequential I/O
> right now out of my small RAID setup,.
>
> I added your patch to the queue for next month's CommitFest and listed
> myself as the initial reviewer, but a commit that soon is unlikely.
> Performance tests like this usually take a while to converge, and
> since this is using a less popular API I expect a round of portability
> concerns, too.
>
> Where did Marc's patch come from? I'd like to be able to separate out
> that change from the rest if necessary.
That patch was posted here:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00000.php> Also, if you have any specific test cases you ran that I could start
> by trying to replicate a speedup on, those would be handy as well.
We experienced synchronized seqscans slowing down after some (10+) clients
which seems to be strange as it should be a strong selling point of 8.3.
With the posix_fadvise() patchs, the dropoff was pushed further.
The query involved multiple tables, it was not a trivial one table
seqscan case.
Without the patch, both a simpler SATA system (each disk at ~63MB/sec)
and a hw RAID with 400+ MB/sec showed slowdown.
The initial 60-63MB/sec with 1-3 clients on the single SATA disk system
quickly dropped to 11-17MB/sec with more clients.
With the patch, it only dropped to 40-47MB/sec.
I cannot recall the RAID figures.
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
>
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
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-patches@postgresql.org
Cc: zb@cybertec.at, gsmith@gregsmith.com, postgres@cybertec.at
Subject: Re: posix advises ...
In-Reply-To: <485B854D.1050200@cybertec.at>
* 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