AIO & DIO for PostgreSQL on FreeBSD* Work in progress report *And other animals Thomas Munro PostgreSQL hacker @ Microsoft PGCon 2022, which should have been in Ottawa
Modernising PostgreSQL’s disk IO And some things I learned about FreeBSD along the journey • PostgreSQL disk AIO project started by Andres Freund, later joined by Thomas Munro, Melanie Plageman, David Rowley, being proposed for PostgreSQL 16 io_method={worker,io_uring,posix_aio,windows_iocp}
io_data_direct={on,off}
io_wal_direct={on,off}
All supported OSes Linux POSIX, especially FreeBSD Windows
Kernel Storage PostgreSQL • RAM is wasted by having two levels of bu ff er
• Data is transferred between caches 8KB at a time with a lot of synchronous pread/pwrite
• Relying on kernel heuristics for readhead and writeback
• We give limited hints about future reads and fsyncs on some OSes for IO concurrency (but not FreeBSD 😔) Bu ff er cache/ARC Bu ff er pool WAL bu ff ers PostgreSQL’s traditional disk I/O
Logic for controlling IO depth is common infrastructure, working in batches, to allow for IO combining;
Research topic: control theory algorithms Logic for how to initiate one more IO is provided by from consumer/ producer Index scans, recovery/ replication system, checkpointer, …
Primary node Replica node A system with many clients can be faulting in pages concurrently Replicas would synchronously fault in one page at a time; fi xed with AIO-based prefetching postgres=# select wal_distance, io_depth from pg_stat_recovery_prefetch;
O_DIRECT • IRIX gave us open(O_DIRECT), widely adopted, but not covered by POSIX so no formal meaning; general idea “don’t bu ff er my data”
• Systems di ff er in details (block alignment requirements, e ff ects on descriptors with di ff erent fl ags, support on di ff erent fi le systems)
• There were also some other ideas: Sun’s directio() and mount options, Apple’s F_NOCACHE
• AFAIK, mostly of interest to database hackers and big data graphics/science
• Speculation: one of the motivations for 90s databases to use raw disk partitions was perhaps to skip the kernel’s bu ff er cache, IO scheduler and concurrency/locking problems; O_DIRECT and highly concurrent fi le systems address those issues
O_DIRECT gives you more problems • Our bu ff er replacement logic and bu ff er pool size had better be good, because the kernel’s bu ff ering won’t be cushioning our misses
• We’ll need to supply readhead, writeback, clustering and concurrency logic, even for the simplest straight-line cases
• -> AIO and DIO go together like peanut butter and jelly
• Slower unbu ff ered reads and writes may reveal locking problems in fi lesystem implementation (gulp)
POSIX AIO: completion APIs • aio_error() to fi nd out if it’s fi nished, failed or EINPROGRESS
• aio_return() to get the result
• aio_suspend() to wait for a list of IOs to complete, then see above to fi nd out which ones (reads and writes only, no fsyncs, though almost all implementations allow sync to be waited for too)
POSIX AIO: standard notification mechanisms • SIGEV_SIGNAL
• sigwaitinfo() can give you read-from-a-queue style interface, at a cost of three syscalls per IO (sigwaitinfo(), aio_error(), aio_return()), but macOS didn’t implement it! You could do sigwait() and then aio_error() for all outstanding IOs, for O(n^2) syscalls…
• Using signal handlers would be unpleasant, and glibc has some questionable async signal safety
• SIGEV_THREAD
• Call a function pointer in some unspeci fi ed thread. As a matter of policy we probably don’t want threads for this, but in any case macOS didn’t implement it…
• SIGEV_NONE
• You’ll have to use aio_suspend() to wait, and then O(n^2). Only HP-UX doesn’t allow aio_fsync() to be waited for with aio_suspend() (which is allowed by POSIX, why?!)
POSIX AIO: extended completion APIs Almost every OS invented a much nicer queue-like system • SIGEV_KEVENT (FreeBSD): drain N from a kqueue
• You still have to call aio_return() on each IO, and possibly aio_error() too*, so you cannot get below 1.x syscalls per IO!
• macOS and NetBSD have both kqueue and AIO, but they are not connected; Dragon fl y removed AIO.
• aio_waitcomplete() (FreeBSD): drain one like a queue; no aio_error() or aio_return()
• AIX’s aio_nwait() (but doesn’t work for aio_fsync()!), Solaris’s aio_waitn(), HP-UX’s aio_reap() could all read batches of completions, some without even entering the kernel
• AIX and Solaris also added Windows IOCP-style APIs (not explored by me; SIGEV_PORT?)
Assorted tricky problems • UFS O_SYNC/O_DSYNC waits *for each block* instead of whole writes
• UFS has a fast bu ff erless path for O_DIRECT reads, but not vector reads (which should ideally produce a single multi-segment read at the device level), and no equivalent for writes
• UFS fsync()/fdatasync() doesn’t fl ush device caches or use FUA
• UFS uses VFS-level writes locks for write() and fsync(), preventing concurrency
• VFS doesn’t allow for true asynchronous IO, instead kernel threads call the synchronous entry points and sleep
Improve AIO completions via kqueue? • I would like to be able to use SEGEV_KEVENT to consume completion events from a kqueue without having to call aio_return(). Then we could get below 1 system call per IO, like on other OSes.
• I have some prototype code for this: see D33271, D33144. It’s tricky, there are many places in the kernel that assume that IO is synchronous…
• I have heard suggestions that kevent() should also be able to start IOs too
macdice
syukai
assu_ming
piyoppi
kinocoboy2
zakky21
codehex
eddie
ruyadorno
os1ma
codemountains
yuhei_fujita
ryos36
lara
lemiorhan
paulrobertlloyd
ddemaree
philhawksworth
dotmariusz
chrislema
palkan
ufuk
tammyeverts
soudai