From: | Zoltan Boszormenyi <zb(at)cybertec(dot)at> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: posix advises ... |
Date: | 2008-06-20 10:24:13 |
Message-ID: | 485B854D.1050200@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
>
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2008-06-20 10:37:01 | Re: ecpg generated files ignorable? |
Previous Message | Gaetano Mendola | 2008-06-20 09:52:03 | Not valid dump [8.2.9, 8.3.1] |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-06-20 16:52:12 | Re: [HACKERS] Hint Bits and Write I/O |
Previous Message | Andrew Dunstan | 2008-06-20 08:00:13 | Re: doc patch - archive/restore_command on windows |