Re: Use fadvise in wal replay
От | Andrey Borodin |
---|---|
Тема | Re: Use fadvise in wal replay |
Дата | |
Msg-id | 979BDEE2-49C1-4420-8578-9182BC2DE875@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: Use fadvise in wal replay (Pavel Borisov <pashkin.elfe@gmail.com>) |
Ответы |
Re: Use fadvise in wal replay
|
Список | pgsql-hackers |
> On 21 Jun 2022, at 20:52, Pavel Borisov <pashkin.elfe@gmail.com> wrote: > > > On 21 Jun 2022, at 16:59, Jakub Wartak <jakub.wartak@tomtom.com> wrote: > Oh, wow, your benchmarks show really impressive improvement. > > FWIW I was trying to speedup long sequential file reads in Postgres using fadvise hints. I've found no detectable improvements. > Then I've written 1Mb - 1Gb sequential read test with both fadvise POSIX_FADV_WILLNEED and POSIX_FADV_SEQUENTIAL in Linux. Did you drop caches? > The only improvement I've found was > > 1. when the size of read was around several Mb and fadvise len also around several Mb. > 2. when before fdavice and the first read there was a delay (which was supposedly used by OS for reading into prefetchbuffer) That's the case of startup process: you read a xlog page, then redo records from this page. > 3. If I read sequential blocks i saw speedup only on first ones. Overall read speed of say 1Gb file remained unchangedno matter what. > > I became convinced that if I read something long, OS does necessary speedups automatically (which is also in agreementwith fadvise manual/code comments). > Could you please elaborate how have you got the results with that big difference? (Though I don't against fadvise usage,at worst it is expected to be useless). FWIW we with Kirill observed drastically reduced lag on a production server when running patched version. Fidvise surelyworks :) The question is how to use it optimally. Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: