Jetson AGX Orin上jetson-inference train.py的num_workers设置求助

一、为什么设置num_workers=4会报共享内存不足错误？ #

你遇到的问题核心不是设备总内存或GPU核心数不够，而是Docker容器默认的共享内存（/dev/shm）配额有限。Jetson设备虽然有64GB统一内存，但Docker容器默认分配的共享内存通常只有1GB甚至更小，每个DataLoader worker都会占用共享内存来缓存和加载数据，当workers数量增加时，很快就会耗尽容器内的共享内存配额，触发报错。

另外，网上“num_workers等于batch-size或GPU核心数”的指南并不适用于Jetson环境：

• Jetson的GPU核心数是CUDA核心数，和CPU的线程/核心数完全是两个概念，num_workers由CPU调度，应该参考CPU核心数（AGX Orin有12个CPU核心），但前提是容器的共享内存足够支撑。
• 统一内存架构下，数据加载的内存占用会和GPU计算的内存需求叠加，即使总内存充足，也可能因为共享内存的限制触发错误。

解决方法： #

• 启动Docker容器时手动指定更大的共享内存，比如：

  docker run --shm-size=16g [其他容器参数]
  

  可以根据实际情况调整大小，比如8g、16g都可测试。
• 先从低数值开始测试num_workers，比如先设1，再逐步增加到2、4、8，直到找到不报错且性能最优的数值，不用强行追CPU核心数。
• 如果batch-size设置得较大，也可以适当减小，降低每个worker的内存占用压力。

二、更多workers能缩短每个epoch的耗时吗？ #

这个观点不完全正确，存在性能瓶颈上限：

• 当workers数量较少时，数据加载会成为训练的瓶颈——GPU经常处于等待CPU加载数据的状态，此时增加workers可以让CPU并行预加载数据，实现数据加载和GPU计算的重叠，确实能缩短epoch耗时。
• 但当workers数量超过CPU的处理能力后，再增加workers会导致CPU频繁进行上下文切换，额外开销增大，不仅不会提升速度，反而可能让耗时增加，甚至触发内存不足问题。
• 在Jetson的统一内存架构下，数据加载的效率和x86平台有差异，最优workers数量需要实际测试得出，而不是照搬通用指南。

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