| From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Cédric Villemain <Cedric(dot)Villemain(at)abcsql(dot)com>, Benoit Lobréau <benoit(dot)lobreau(at)dalibo(dot)com>, Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
| Subject: | Re: Add time spent in posix_fadvise() in I/O read time ? |
| Date: | 2025-03-19 13:25:51 |
| Message-ID: | 8c4ec02f-763c-465c-adf3-801c8cbf02a5@dalibo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/14/25 09:43, Frédéric Yhuel wrote:
> One thing I've noticed is that posix_fadvise(,,POSIX_FADV_WILLNEED)
> isn't always non-blocking on Linux. As Ted Ts'o explains in this old
> thread[1], it blocks when the request queue fills up.
When posix_fadvise() blocks, it doesn't seem to be completely off-cpu
(but mostly, at least on my machine), and I assume that this is the
reason for the sentence "A value higher than needed to keep the disks
busy will only result in extra CPU overhead" in the documentation for
effective_io_concurrency? My guess is that Linux uses a spinlock
somewhere, and that this explains the cpu overhead.
Also, on Linux, it seems we can control the size of the request queue
with the /sys/block/XXX/queue/nr_requests setting. On my machine, it is
set to 64 by default. When I set it up to 128, postgres spends less time
on posix_fadvise(), and correspondingly more on pread().
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2025-03-19 13:31:42 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
| Previous Message | Greg Sabino Mullane | 2025-03-19 13:24:19 | Re: PATCH: warn about, and deprecate, clear text passwords |