From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | Hannu Krosing <hannu(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com> |
Subject: | Re: 9.4 regression |
Date: | 2013-08-09 02:27:31 |
Message-ID: | 20130809022731.GL14729@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-08-08 16:12:06 -0500, Jon Nelson wrote:
> On Thu, Aug 8, 2013 at 2:50 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> > On 08/08/2013 05:28 PM, Jon Nelson wrote:
> ...
>
> > Just an idea - can you check if using a fillfactor different form 100
> > changes anything
> >
> > pgbench -s 20 -p 54320 -d pgb -F 90 -i
> >
> >
> >> pgbench -j 80 -c 80 -T 120 -p 54320 pgb
> >> pg_ctl -D tt -w stop
> >
> > That is, does extending tables and indexes to add updated tuples play
> > any role here
>
> I gave it a go - it didn't make any difference at all.
> At this point I'm convinced that the issue is a pathological case in
> ext4. The performance impact disappears as soon as the unwritten
> extent(s) are written to with real data. Thus, even though allocating
> files with posix_fallocate is - frequently - orders of magnitude
> quicker than doing it with write(2), the subsequent re-write can be
> more expensive. At least, that's what I'm gathering from the various
> threads.
> Why this issue didn't crop up in earlier testing and why I
> can't seem to make test_fallocate do it (even when I modify
> test_fallocate to write to the newly-allocated file in a mostly-random
> fashion) has me baffled.
It might be kernel version specific and concurrency seems to play a
role. If you reproduce the problem, could you run a "perf record -ga" to
collect a systemwide profile?
There's some more things to test:
- is the slowdown dependent on the scale? I.e is it visible with -j 1 -c
1?
- Does it also occur in synchronous_commit=off configurations? Those
don't fdatasync() from so many backends, that might play a role.
- do bulkloads see it? E.g. the initial pgbench load?
> Should this feature be reconsidered?
Let's try to get to the ground of this for a bit more. From the outset
we've said that we're using this as a testbed for extending the
fallocate() usage.
It's not like 9.4 beta1 is going to be released anytime soon.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-08-09 02:32:17 | Proposal: leave a hint when switching logging away from stderr |
Previous Message | Jon Nelson | 2013-08-08 22:44:05 | Re: 9.4 regression |