Re: Performance implications of 8K pread()s

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Performance implications of 8K pread()s
Дата
Msg-id 20230717153432.5qm6ywcdhhl5m2ny@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Performance implications of 8K pread()s  (Dimitrios Apostolou <jimis@gmx.net>)
Список pgsql-performance
Hi,

On 2023-07-17 16:42:31 +0200, Dimitrios Apostolou wrote:
> Thanks, it sounds promising! Are the changes in the 16 branch already,
> i.e. is it enough to fetch sources for 16-beta2?

No, this is in a separate branch.

https://github.com/anarazel/postgres/tree/aio


> If so do I just configure --with-liburing (I'm on linux) and run with
> io_method=io_uring?

It's probably worth trying out both io_uring and worker. I've not looked at
performance on btrfs. I know that some of the optimized paths for io_uring
(being able to perform filesystem IO without doing so synchronously in an
in-kernel thread) require filesystem cooperation, and I do not know how much
attention btrfs has received for that.


> Else, if I use the io_method=worker what is a sensible amount of worker
> threads?

Depends on your workload :/. If you just want to measure whether it fixes your
single-threaded query execution issue, the default should be just fine.


> Should I also set all the flags for direct I/O?  (io_data_direct=on
> io_wal_direct=on).

FWIW, I just pushed a rebased version to the aio branch, and there the config
for direct io is
io_direct = 'data, wal, wal_init'
(or a subset thereof).

From what I know of btrfs, I don't think you want direct IO though. Possibly
for WAL, but definitely not for data. IIRC it currently can cause corruption.

Greetings,

Andres Freund



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

Предыдущее
От: Dimitrios Apostolou
Дата:
Сообщение: Re: Performance implications of 8K pread()s
Следующее
От: Piyush Katariya
Дата:
Сообщение: TOAST Fields serialisation/deserialization performance