blockdev --setra 仅在流媒体读取满足顺序、缓存、无跳转前提时有效，通过预加载数据到 page cache 减少磁盘等待；需用 strace 确认是否走 buffered I/O 且 offset 递增，推荐值按码率设定（如高清 8MB），SSD 上收益有限，验证需清缓存并观察 iostat 指标变化。
blockdev --setra 能优化流媒体读取，但效果取决于是否满足“顺序、缓存、无跳转”三个前提。它不直接加速单次读，而是让内核提前把后续数据载入 page cache，减少磁盘等待。盲目调大反而可能拖慢系统，尤其在多任务或内存紧张时。
先确认流媒体读取是否走预读路径
很多流媒体服务（如ffmpeg、gstreamer后端、自研播放器）默认用 buffered I/O，但若启用了 O_DIRECT、频繁 lseek() 跳帧、或使用内存映射（mmap + MAP_POPULATE），预读就会被绕过。
- 用 strace -e trace=open,read,lseek,openat 运行你的流媒体进程，观察 read() 系统调用的 offset 是否单调递增
- 若出现大量 lseek() 后紧跟 read()，或 read() 返回值远小于预期（如每次只读几 KB），说明不是纯顺序流，--setra 收效甚微
- 检查是否用了 O_DIRECT：看 strace 中 open() 的 flags 是否含 O_DIRECT（值通常为 0x4000）
合理设置 --setra 值（单位是 512 字节扇区）
流媒体典型码率在 2–20 MB/s，对应每秒需读 4K–40K 扇区。预读值应略大于“1–2 秒内待读数据量”，而非越大越好。
- 默认值通常是 256（即 128 KB），对高清直播流偏小；可先试 --setra 8192（4 MB），再根据实际吞吐调整
- 常见推荐：
• 标清/音频流（≤2 MB/s）→ 4096（2 MB）
• 高清（5–10 MB/s）→ 16384（8 MB）
• 4K 流（15+ MB/s）→ 32768（16 MB），但需确保空闲内存 ≥ 2× 预读值 - SSD 上收益有限，因随机读延迟低；若用 NVMe，建议保持默认或仅小幅上调（如 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 设备名可能变化，优先绑定 by-id 或 by-uuid
比 --setra 更精准的替代方案
如果流媒体程序支持编程控制，posix_fadvise(fd, offset, len, POSIX_FADV_WILLNEED) 是更优选择。
- 它按文件句柄粒度触发预加载，不影响其他进程，也不会污染全局 page cache
- 可在解码线程中预测下一段数据位置，提前 hint，比设备级预读响应更快、更可控
- ffmpeg 已内置类似逻辑（通过 -probesize/-analyzeduration 控制探测行为），升级到较新版本往往比手动调 --setra 更有效
