posix advises ...

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: pgsql-patches <pgsql-patches(at)postgresql(dot)org>, Zoltan Boszormenyi <zb(at)cybertec(dot)at>
Subject: posix advises ...
Date: 2008-05-11 09:53:04
Message-ID: 4826C200.8060807@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

hello everybody,

recently we had a bit of a nightmare with some kernels and concurrent
seq scans.
the thing we encountered was the following: a single "SELECT COUNT(*)
FROM table" on a big table (50 gb) gave us constant 350 mb / sec I/O. as
soon as a second scan dropped in speed dropped to 2 mb / sec. first i
thought that some random I/O dropped in but synchronous scans worked
fine. we found out that there is some madness in some linux kernel /
controller combinations causing this issue.
it did some tests on my local boxes which was clearly not affected by
this problem and I have seen a single SATA disks dropping from 65 mb /
sec to around 45. this is not good.
i found a patch by grep stark implementing posix_fadvise for bitmap
scans. i quickly hacked in suggestions to issue the same advises when a
seq scan is done.
the impact was surprisingly high. single scans went up from 65 mb / sec
to something around 70. concurrent scans are basically at steady, high
speed - no dropping I/O speed anymore until something like 16 scans or so.
even the broken controller when up from "350mb -> 2mb" to "350 -> 50mb".
by replacing the kernel and the driver we see steady behavior here as
well now.

maybe it is worth to discuss posix_fadvise.
we hacked up a simple patch based on greg's work which nicely fixed the
problem for us (brute force).
we also made some simple autoconf hack to check for broken posix_fadvise.
maybe people want to test if they see similar performance differences.
if a patch like that is likely to be accepted we would hack up some more
clean implementation.

many thanks,


Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com

Attachment Content-Type Size
preread-seq-tunable.diff.gz application/x-gzip 96.3 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Hans-Juergen Schoenig 2008-05-11 10:05:44 XIDs and big boxes again ...
Previous Message Tino Wildenhain 2008-05-11 09:13:05 Re: Setting a pre-existing index as a primary key

Browse pgsql-patches by date

  From Date Subject
Next Message daveg 2008-05-11 11:30:47 pg_dump lock timeout
Previous Message Nikhils 2008-05-11 07:57:49 Re: [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]