Re: a question about Direct I/O and double buffering
От | Erik Jones |
---|---|
Тема | Re: a question about Direct I/O and double buffering |
Дата | |
Msg-id | CE3B7895-88D9-4CEC-A9EC-506AD4533300@myemma.com обсуждение исходный текст |
Ответ на | Re: a question about Direct I/O and double buffering (Mark Lewis <mark.lewis@mir3.com>) |
Ответы |
Re: a question about Direct I/O and double buffering
|
Список | pgsql-performance |
On Apr 5, 2007, at 2:56 PM, Mark Lewis wrote:
...[snipped for brevity]...Not to hijack this thread, but has anybody here tested the behaviorofPG on a file system with OS-level caching disabled via forcedirectioorby using an inherently non-caching file system such as ocfs2?I've been thinking about trying this setup to avoid double-cachingnowthat the 8.x series scales shared buffers better, but I figured I'daskfirst if anybody here had experience with similar configurations.-- MarkRather than repeat everything that was said just last week, I'll pointout that we just had a pretty decent discusson on this last week thatI started, so check the archives. In summary though, if you have ahigh io transaction load with a db where the average size of your"working set" of data doesn't fit in memory with room to spare, thendirect io can be a huge plus, otherwise you probably won't see much ofa difference. I have yet to hear of anybody actually seeing anydegradation in the db performance from it. In addition, while itdoesn't bother me, I'd watch the top posting as some people get prettyreligious about (I moved your comments down).I saw the thread, but my understanding from reading through it was thatyou never fully tracked down the cause of the factor of 10 write volumemismatch, so I pretty much wrote it off as a data point forforcedirectio because of the unknowns. Did you ever figure out thecause of that?-- Mark Lewis
Nope. What we never tracked down was the factor of 10 drop in database transactions, not disk transactions. The write volume was most definitely due to the direct io setting -- writes are now being done in terms of the system's block size where as before they were being done in terms of the the filesystem's cache page size (as it's in virtual memory). Basically, we do so many write transactions that the fs cache was constantly paging.
erik jones <erik@myemma.com>
software developer
615-296-0838
emma(r)
В списке pgsql-performance по дате отправления: