fsync, fdatasync, open_sync, and open_datasync, -- Linux insanity

Поиск
Список
Период
Сортировка
От pgsql@mohawksoft.com
Тема fsync, fdatasync, open_sync, and open_datasync, -- Linux insanity
Дата
Msg-id 8244.64.119.142.34.1092232402.squirrel@mail.mohawksoft.com
обсуждение исходный текст
Ответы Re: fsync, fdatasync, open_sync, and open_datasync, -- Linux insanity  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Maybe I'm losing it, but I forced to apologize for trying to push for
"open_sync" as the default.

I have spent the last few days trying to come to some solid, documented
and verifyable, conclusions about which is the best fsync method. At a
minimum, what is the best fsync method for Linux. I can't find one.

On some systems fsync and fdatasync perform the same and open_sync is a
clear winner(RedHat 9, 2.4.25), on another system (Mandrake 10.0
community, also 2.4.25) fdatasync is clearly better than fsync and
performs the same as open_sync. (Using the same file system, ext2) I'm
also pretty sure it will be different on different hardware, and
open_datasync doesn't even work.

The problem that I have with this is that we are not talking about a
couple percentage points of performance that can be ignored for
simplicity, sometimes it is twice the performance, sometimes it is almost
10 times the performance, and there is no clear answer: "If you use X, you
should set Y."

I know for me, I didn't actually think the wal_sync_method would make much
difference until I tried all of them. (I bet most people will never adjust
the default) Maybe it is just a documentation issue. Maybe a short
discussion about various operating systems making different choices, and
how the administrator should try each for their application as there is
*no* definitive answer and that it could make a huge difference. I don't
know. It is just disturbing that it can make such a HUGE difference and it
is hardly discussed anywhere.

What would be a good strategy for addressing this issue? Is it an issue at
all? Is it simply a documentation issue? Do we craft some sort of test
that can characterize the behavior? What would that test need to do?

For what its worth, using open_sync, on a specific clients hardware and
OS, made the difference between running with fsync "on" and "off,"
choosing "on." Had we not tryied it, performance would have been too slow
to enable it.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: libpq problem
Следующее
От: Oliver Jowett
Дата:
Сообщение: SAVEPOINT syntax again