On 2013-08-08 16:12:06 -0500, Jon Nelson wrote: > On Thu, Aug 8, 2013 at 2:50 PM, Hannu Krosing <ha...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
