On Wed, 2012-03-14 at 10:26 +0100, Andres Freund wrote: > On Wednesday, March 14, 2012 05:23:03 AM Jeff Davis wrote: > > On Tue, 2012-03-13 at 09:42 +0100, Andres Freund wrote: > > > for recursively everything in dir: > > > posix_fadvise(fd, POSIX_FADV_DONTNEED); > > > > > > for recursively everything in dir: > > > fsync(fd); > > > > Wow, that made a huge difference! > > > > no sync: ~ 1.0s > > sync: ~10.0s > > fadvise+sync: ~ 1.3s
I take that back. There was something wrong with my test -- fadvise
helps, but it only takes it from ~10s to ~6.5s. Not quite as good as I
hoped.
> Well, while the positive effect of this are rather large it also has the bad
> effect of pushing the whole new database out of the cache. Which is not so
> nice
> if you want to run tests on it seconds later.
I was unable to see a regression when it comes to starting it up after
the fadvise+fsync. My test just started the server, created a table,
then stopped the server. It was actually a hair faster with the
directory that had been fadvise'd and then fsync'd, but I assume that
was noise. Regardless, this doesn't look like an issue.
> How are the results with sync_file_range(fd, 0, 0,
> SYNC_FILE_RANGE_WRITE)?
That is much faster than using fadvise. It goes down to ~2s.
Unfortunately, that's non-portable. Any other ideas? 6.5s a little on
the annoying side (and causes some disconcerting sounds to come from my
disk), especially when we _know_ it can be done in 2s.
Anyway, updated patch attached.
Regards,
Jeff Davis
initdb-fsync-20120314.patch.gz
Description: GNU Zip compressed data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
