Re: Help me develop new commit_delay advice
От | Amit Kapila |
---|---|
Тема | Re: Help me develop new commit_delay advice |
Дата | |
Msg-id | 002401cd70a0$1837a2b0$48a6e810$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: Help me develop new commit_delay advice (Peter Geoghegan <peter@2ndquadrant.com>) |
Список | pgsql-hackers |
> From: Peter Geoghegan [mailto:peter@2ndquadrant.com] > Sent: Wednesday, August 01, 2012 8:49 PM On 1 August 2012 15:14, Amit Kapila <amit.kapila@huawei.com> wrote: >> I shall look into this aspect also(setting commit_delay based on raw sync). >> You also suggest if you want to run the test with different configuration. > Well, I was specifically interested in testing if half of raw sync > time was a widely useful setting, across a variety of different, > though representative I/O subsystems. Unfortunately, without some > context about raw sync speed to go along with your numbers, I cannot > advance or disprove that idea. Raw sync speed data -------------------------- 2 seconds per test O_DIRECT supported on this platform for open_datasync and open_sync. Compare file sync methods using one 8kB write: (in wal_sync_method preference order, except fdatasync is Linux's default) open_datasync n/a fdatasync 165.506ops/sec fsync 166.647 ops/sec fsync_writethrough n/a open_sync 164.654 ops/sec 165.506 * 8KB operations can perform in one sec. so 1 * 8KB operation takes 6.042 msec. > It would also have been nice to see a baseline number of 0 too, to get > an idea of how effective commit_delay may now be. However, that's > secondary. In the data sent yesterday commit_delay=0 was there. With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: