Colab RAM统计与process.memory_info().rss结果不符原因问询

核心差异来源 #

• 统计口径完全不同
  • process.memory_info().rss统计的是当前Python主进程的驻留物理内存，仅统计主进程自身独占的物理内存，不会包含子进程占用、内核态内存映射、系统页面缓存等部分的内存消耗。
  • Colab的RAM统计的是整个Colab虚拟机实例的总内存占用，包含系统进程、Jupyter内核服务、所有Python子进程、CUDA驱动内核态映射内存、系统页面缓存等所有内存消耗。

常见导致偏差的场景 #

1. PyTorch DataLoader多进程开销 #

如果你设置了DataLoader的num_workers > 0，每个数据加载worker都是独立的子进程，这些子进程的内存占用完全不会被主进程的rss统计到，但会被计入Colab总RAM。如果子进程加载数据时存在未释放的缓存、或者迭代过程中不断产生未回收的对象，就会出现总RAM持续上涨，但主进程rss几乎不变的情况。

2. Jupyter输出缓存占用 #

Jupyter默认会保留所有历史输出的引用，如果你每次迭代会输出大张量、生成图片、打印大体积内容，这些输出会一直缓存在内存中，这部分消耗不会被算入主进程的rss统计，但会占用实例总内存。

3. PyTorch内存池与CUDA映射内存 #

PyTorch会自行维护CPU/GPU内存池，已经释放的张量内存不会立刻归还给操作系统，而是留在池内供后续分配使用；同时CUDA驱动会在内核态保留一部分主存空间做显存映射，这两部分内存都会被计入Colab总RAM，但不会完全反映在主进程的rss数值中。

4. 系统页面缓存 #

操作系统会将读取过的数据集、文件等内容缓存在内存中提升读取速度，这部分缓存会被Colab计入已用RAM，但不属于任何进程的rss统计范围。

排查方法 #

• 先将DataLoader的num_workers设置为0，重新运行训练流程，如果内存不再上涨，即可定位为子进程内存消耗问题，可调整子进程加载逻辑、定期重启worker解决。
• 关闭Jupyter历史输出缓存，或者每次迭代后清理无用输出，观察总RAM变化。
• 使用psutil遍历当前主进程的所有子进程，汇总所有进程的rss后再和Colab统计值对比，即可验证是否为子进程开销导致的偏差。
• 每次迭代后调用torch.empty_cache()主动释放PyTorch内存池中的闲置内存，观察数值变化。

内容的提问来源于stack exchange，提问作者Dmitry