Re: a question about Direct I/O and double buffering

Поиск
Список
Период
Сортировка
От Erik Jones
Тема Re: a question about Direct I/O and double buffering
Дата
Msg-id 54F6CC69-51C5-4BA1-AC08-916279684C7D@myemma.com
обсуждение исходный текст
Ответ на Re: a question about Direct I/O and double buffering  (david@lang.hm)
Ответы Re: a question about Direct I/O and double buffering
Список pgsql-performance

On Apr 5, 2007, at 3:33 PM, david@lang.hm wrote:

On Thu, 5 Apr 2007, Xiaoning Ding wrote:


 To the best of my knowledge, Postgres itself does not have a direct IO
 option (although it would be a good addition).  So, in order to use direct
 IO with postgres you'll need to consult your filesystem docs for how to
 set the forcedirectio mount option.  I believe it can be set dynamically,
 but if you want it to be permanent you'll to add it to your fstab/vfstab
 file.

I use Linux.  It supports direct I/O on a per-file basis only.  To bypass OS buffer cache,
files should be opened with O_DIRECT option.  I afraid that I have to modify PG.

as someone who has been reading the linux-kernel mailing list for 10 years, let me comment on this a bit.

linux does have a direct i/o option,

Yes, I know applications can request direct i/o with the O_DIRECT flag to open(), but can this be set to be forced for all applications or for individual applications from "outside" the application (not that I've ever heard of something like the second)?

but it has significant limits on when and how you cna use it (buffers must be 512byte aligned and multiples of 512 bytes, things like that).

That's a standard limit imposed by the sector size of hard drives, and is present in all direct i/o implementations, not just Linux.

Also, in many cases testing has shon that there is a fairly significant performance hit for this, not a perfomance gain.

Those performance hits have been noticed for high i/o transaction databases?  The idea here is that these kinds of database manage their own caches and having a separate filesystem cache in virtual memory that works with system memory page sizes is an unneeded level of indirection.  Yes, you should expect other "normal" utilities will suffer a performance hit as if you are trying to cp a 500 byte file you'll still have to work with 8K writes and reads whereas with the filesystem cache you can just write/read part of a page in memory and let the cache decide when it needs to write and read from disk.  If there are other caveats to direct i/o on Linux I'd love to hear them.

erik jones <erik@myemma.com>
software developer
615-296-0838
emma(r)



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

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: SCSI vs SATA
Следующее
От: Vincenzo Romano
Дата:
Сообщение: Re: Weird performance drop