add 2025-01-02_direct-io.md #45
Conversation
Signed-off-by: machine424 <[email protected]>
|
|
||
|  | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Using posix_fadvise with POSIX_FADV_DONTNEED could be an option if it doesn't make sense to totally avoid the cache (there's also Linux specific memory management options like MADV_COLD, which could help for some of the container concerns to optimise which memory is reclaimed, although it wouldn't likely have as much user visible impact on the page cache).
I suspect those don't make sense for the TSDB but could be worth mentioning here, there might be other places in the ecosystem where those make more sense than O_DIRECT.
There was a problem hiding this comment.
Thnaks, I'll mention that.
|
|
||
| In addition to the issues mentioned above, sometimes the page cache generated during writes is not | ||
| used at all. For instance, once chunks are written during compaction, they are opened via | ||
| `mmap`, which renders the page cache produced during writing redundant and useless. |
There was a problem hiding this comment.
I'm not sure that's entirely true, Linux has a merged page + buffer cache: https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics#Page_Cache_or_Buffer_Cache
(The exception being OpenBSD, see prometheus/prometheus#8799)
There was a problem hiding this comment.
You're right, I'll make that clearer.
kick off PR prometheus/prometheus#15365