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 по дате отправления: