blockdev --setra 能提升大规模顺序读效率，但仅在满足“顺序读、buffered i/o、无跳转”前提下有效；它通过预加载后续数据到 page cache 减少磁盘等待，需用 strace 确认读模式，按码率设合理扇区值（如高清流设 16384），ssd 上收益有限，验证须清缓存并观察 iostat 指标变化。
blockdev --setra 能提升大规模顺序读的效率，但不是简单调大就有效。它本质是让内核在读取当前数据时，顺带把后续一段连续数据提前加载进 page cache，减少磁盘等待。前提是：必须是顺序读、走 buffered I/O、无跳转。不满足这三点，调再大也没用。
确认是否真走预读路径
很多流媒体程序看似顺序读，实则被绕过预读机制： - 用 `strace -e trace=open,read,lseek,openat` 启动你的播放或转码进程（如 ffmpeg） - 观察 `read()` 系统调用的 offset 是否单调递增；若频繁出现 `lseek()` 后紧跟 `read()`，说明有跳帧或 seek 行为，预读失效 - 检查 `open()` 的 flags 是否含 `O_DIRECT`（strace 中显示为 `0x4000`），启用后直接绕过 page cache，`--setra` 完全无效设置合理值（单位是 512 字节扇区）
预读值不是越大越好，而是匹配你的数据吞吐节奏： - 默认值通常是 256（即 128 KB），对高清流偏小 - 推荐按“1–2 秒内待读数据量”估算： • 标清/音频流（≤2 MB/s）→ 设 `--setra 4096`（2 MB） • 高清（5–10 MB/s）→ 设 `--setra 16384`（8 MB） • 4K 流（15+ MB/s）→ 可试 `--setra 32768`（16 MB），但需确保空闲内存 ≥ 2× 该值 - SSD/NVMe 上收益有限，建议保持默认或仅小幅上调（如 `--setra 512`～`1024`），避免无效 IO 和 CPU 开销验证效果要清缓存 + 看指标
临时设置后不会立刻体现，需真实负载下观察： - 查当前值：`blockdev --getra /dev/sdX` 或 `cat /sys/block/sdX/queue/read_ahead_kb`（注意后者单位是 KB） - 清缓存再测：`sync && echo 3 > /proc/sys/vm/drop_caches` - 启动流媒体，同时运行 `iostat -xm 1` 监控： • 若 `r/s` 下降、`avgrq-sz` 上升、`%util` 稳定、实际读速提升 → 说明 IO 合并有效 • 若 `await` 波动剧烈或 `%util` 接近 100% → 预读过大引发竞争，需调小 - 该设置重启即失效。如需持久化，可写 udev 规则（如 `/etc/udev/rules.d/60-readahead.rules`），但注意 LVM/RAID 设备名可能变化别忽略设备选择和系统影响
- 不要对系统盘（如 `/dev/sda`）盲目调大，可能拖慢 shell 响应、日志写入等交互任务 - 若多个进程并发读不同大文件，建议维持默认或略增，避免 page cache 资源争抢 - `blockdev --setra` 是设备级全局设置；更精准的替代方案是应用层调用 `posix_fadvise(fd, offset, len, POSIX_FADV_WILLNEED)`，由程序自己控制预取时机和范围不复杂但容易忽略
