Re: fallocate / posix_fallocate for new WAL file creation (etc...)
От | Greg Smith |
---|---|
Тема | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
Дата | |
Msg-id | 51D0C400.1080001@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: fallocate / posix_fallocate for new WAL file creation (etc...) (Jon Nelson <jnelson+pgsql@jamponi.net>) |
Ответы |
Re: fallocate / posix_fallocate for new WAL file creation (etc...)
|
Список | pgsql-hackers |
On 5/28/13 10:00 PM, Jon Nelson wrote: > A note: The attached test program uses *fsync* instead of *fdatasync* > after calling fallocate (or writing out 16MB of zeroes), per an > earlier suggestion. I tried this out on the RHEL5 platform I'm worried about now. There's something weird about the test program there. If I run it once it shows posix_fallocate running much faster: without posix_fallocate: 1 open/close iterations, 1 rewrite in 23.0169s with posix_fallocate: 1 open/close iterations, 1 rewrite in 11.1904s The problem is that I'm seeing the gap between the two get smaller the more iterations I run, which makes me wonder if the test is completely fair: without posix_fallocate: 2 open/close iterations, 2 rewrite in 34.3281s with posix_fallocate: 2 open/close iterations, 2 rewrite in 23.1798s without posix_fallocate: 3 open/close iterations, 3 rewrite in 44.4791s with posix_fallocate: 3 open/close iterations, 3 rewrite in 33.6102s without posix_fallocate: 5 open/close iterations, 5 rewrite in 65.6244s with posix_fallocate: 5 open/close iterations, 5 rewrite in 61.0991s You didn't show any output from the latest program on your system, so I'm not sure how it behaved for you here. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: