![当对同一文件进行并发读取时,Linux 会提前读取](https://linux22.com/image/191921/%E5%BD%93%E5%AF%B9%E5%90%8C%E4%B8%80%E6%96%87%E4%BB%B6%E8%BF%9B%E8%A1%8C%E5%B9%B6%E5%8F%91%E8%AF%BB%E5%8F%96%E6%97%B6%EF%BC%8CLinux%20%E4%BC%9A%E6%8F%90%E5%89%8D%E8%AF%BB%E5%8F%96.png)
当按顺序读取文件时,Linux 会执行预读(在 /sys/block//queue/read_ahead_kb 中指定)。
感兴趣的操作系统:红帽Linux 感兴趣的文件系统:xfs、ext4
决定顺序读取完成的标准是什么?考虑使用 pread (https://man7.org/linux/man-pages/man2/pwrite.2.html)具有相同或不同的 FD。
例如
相同的FD。读取位置 10-20-30-78-89(超出 seq 读取)-40-50-60-70 - 23-34(超出 seq 读取)- 80-90-100...
在这种情况下,上述微妙的乱序读取是否可以避免预读?
如果是这样,使用两个不同的 FD 是否可以解决此问题(即使用单独的 FD 来读取 78-89-23-34)? (即预读将照常进行 10-20-30-40-50 次读取)
答案1
在这种情况下,上述微妙的乱序读取是否可以避免预读?
是的,从同一文件描述符中进行乱序读取可能会影响预读,但内核会尝试考虑到这一点——至少对于与顺序读取并行的小型“随机”读取而言。看按需预读设计的描述, 尤其:
在交错顺序读取中,同一 fd 上的并发流可能会使彼此的预读状态无效。因此,我们使用 PG_readahead 标记 (start+size-async_size) 处的新预读页面,并将其用作预读指示器。该标志不会在已缓存的页面上设置,以避免无意义的预读,从而节省无意义的页面缓存查找。
您可以通过查看来了解它的适用范围ondemand_readahead
, 尤其它的呼吁try_context_readahead
以及周围的评论。
与往常一样,在尝试消除性能瓶颈时,您不应该考虑潜在的瓶颈,除非作为提示:您应该设计自己的基准并分析特定场景的性能特征。例如,可能的情况是,您的失序读取仅命中了由于顺序读取的预读而已经存在于页面缓存中的页面。