本人工作中遇到的实际问题结合大模型分析后找到了原因本文在CHATGPT帮助下完成1. 问题背景在使用 PyNvVideoCodec 做 GPU 视频解码测试时发现一个非常奇怪的现象同一个视频第一次运行PyNvVideoCodec decode: 10s第二次运行PyNvVideoCodec decode: 2s代码、GPU、Docker 环境完全没有变化。初步怀疑PyNvVideoCodec 第一次初始化慢NVDEC 有缓存Qwen 模型加载影响Docker 容器导致GPU 驱动问题经过多组实验最终定位真正影响性能的是 Linux Page Cache文件缓存而不是 GPU 解码本身。2. Linux Page Cache 是什么Linux 不会每次读取文件都直接访问磁盘。当程序读取文件程序 | | read() ↓ Linux Kernel | ↓ 磁盘第一次读取磁盘 ↓ Page Cache ↓ 程序Linux 会把读取的数据缓存在内存中。第二次读取程序 | ↓ Page Cache | ↓ 直接返回不需要再次访问磁盘。因此第一次磁盘 IO 解码第二次内存读取 解码速度可能产生明显差异。3. 为什么 Docker 重启后缓存还存在很多人会误以为Docker 容器退出后缓存应该消失。实际上不是。Page Cache 属于Linux Kernel不是Docker Container例如第一次Docker A 读取 video.mp4 ↓ Linux Page Cache然后Docker A退出但是Linux Kernel仍然运行。再次Docker B 读取同一个 video.mp4仍然可以命中之前的 Page Cache。所以不同 docker run 之间可以共享文件缓存。4. 如何查看一个文件是否已经缓存推荐工具vmtouch安装Ubuntusudoaptinstallvmtouch查看文件vmtouch video.mp4输出Files: 1 Directories: 0 Resident Pages: 121973/121973 476M/476M 100% Elapsed: 0.000458 secondsResident Pages 怎么理解Linux 使用 Page 管理内存。通常1 Page 4096 Bytes例如视频476MB大约476MB / 4KB ≈121973 Pages输出Resident Pages: 121973 / 121973表示总页数: 121973 已经在内存中的页: 121973也就是100%代表整个视频已经进入 Linux Page Cache。如果Resident Pages: 50000 / 121973 40%说明只有 40% 的视频数据已经缓存。5. 查看目录缓存情况查看整个目录vmtouch /data/videos递归查看vmtouch-r/data/videos例如Files: 100 Directories: 1 Resident Pages: 500000/800000 62%表示目录下所有文件约 62% 已经在内存缓存。6. 如何清理 Linux Page Cache性能测试时经常需要模拟第一次访问文件冷缓存可以使用方法一清理整个系统缓存执行sudosh-csync echo 3 /proc/sys/vm/drop_caches解释sync把脏数据写回磁盘RAM ↓ 磁盘避免数据丢失。echo 3含义1: 清理 Page Cache 2: 清理 inode/dentry cache 3: 两者都清理一般测试使用3清理后验证vmtouch video.mp4应该之前Resident Pages: 121973/121973 100%变成Resident Pages: 0/121973 0%7. 更推荐只清理指定文件缓存如果只是测试某个视频不建议清理整个系统缓存。使用sudovmtouch-evideo.mp4其中-e evict表示将该文件从 Page Cache 中移除。验证vmtouch video.mp4看到0%即可。8. 一个完整的视频解码测试流程例如测试 PyNvVideoCodec第一步清缓存sudovmtouch-evideo.mp4确认vmtouch video.mp4结果0%第二步运行解码第一次decoder[i] 10s第三步查看缓存vmtouch video.mp4结果100%说明视频已经进入 Page Cache。第四步再次运行第二次decoder[i] 2s原因Page Cache命中9. top/free 能看到这些缓存吗很多人会使用top查看内存。注意Page Cache 不属于某个进程。所以top RES不会包含文件缓存。查看free-h可以看到buff/cache但这个包含Page Cacheinode cacheslab 等不是精确的文件缓存。如果想知道某个视频是否缓存使用vmtouch更准确。10. 对视频处理系统的启示对于视频分析任务例如NAS | 复制 | 本地SSD | PyNvVideoCodec | Qwen | MediaPipe推荐不要直接从网络文件系统做随机帧读取。原因视频随机访问decoder[idx]会频繁触发seek read decode网络存储延迟会直接影响解码时间。更稳定的架构NAS作为存储 ↓ 复制到本地SSD ↓ GPU解码这样性能更加稳定也方便测试。总结Linux Page Cache 是导致第一次读取慢 第二次读取快的主要原因之一。关键命令查看文件缓存vmtouchfile清理单个文件sudovmtouch-efile清理系统缓存sudosh-csync echo 3 /proc/sys/vm/drop_caches对于视频解码性能测试必须区分磁盘/NAS读取性能Page Cache命中GPU解码性能否则容易误判“GPU解码慢”实际上可能只是“第一次读取文件慢”。