直接在docker-compose.yml中设置shm_size是解决分布式计算场景下/dev/shm映射溢出最常用、最稳妥的方式；默认64MB容量在PyTorch DataLoader多worker、MPI通信或Spark shuffle阶段极易耗尽，导致“No space left on device”或静默崩溃。
直接在 docker-compose.yml 中设置 shm_size 是解决分布式计算场景下 /dev/shm 映射溢出最常用、最稳妥的方式。默认 64MB 容量在 PyTorch DataLoader 多 worker、MPI 进程通信或 Spark on Kubernetes 的 shuffle 阶段极易耗尽，导致“No space left on device”或静默崩溃。
为什么分布式计算特别容易触发 shm 溢出
分布式计算框架普遍依赖高频、小块、多进程共享内存进行中间数据交换：
- PyTorch 的
DataLoader(num_workers>0)使用 POSIX 共享内存传递预处理图像/张量，每个 worker 独立占用 shm 缓冲区 - Horovod 或 torch.distributed 启动的多个进程，通过
/dev/shm建立 NCCL 通信临时通道 - Spark executor 在 shuffle write/read 阶段，若启用
spark.shuffle.spill.compress=false或使用内存敏感序列化器，会大量写入 shm - FFmpeg + MPI 联合视频分片转码时，各 rank 进程需共享帧元数据与状态缓冲区
Compose 中正确配置 shm_size 的方法
必须显式声明，不能依赖继承或环境变量。支持大小单位包括 b、k、m、g（不区分大小写），推荐用小写避免解析歧义：
- 基础写法（YAML 字符串格式）：
services: trainer: image: pytorch:2.3-cuda12.1 shm_size: '2g' - 若需更精确控制（如 1.5GB），可换算为字节后写整数：
shm_size: 1610612736 - 多服务协同时，每个需共享内存的服务都应单独设置，例如：
services: worker-0: image: dist-app:latest shm_size: '2g' worker-1: image: dist-app:latest shm_size: '2g' coordinator: image: dist-app:latest shm_size: '512m'
验证与调优建议
启动后务必进入容器确认实际挂载效果，而非仅看配置是否生效：
- 执行
docker-compose exec trainer df -h /dev/shm，输出应显示Size与配置一致（如2.0G） - 观察应用日志中是否仍有
shm_open、mmap或ENOMEM相关错误 - 对典型负载做压力测试：逐步提高
num_workers或 batch size，记录 shm 使用峰值（可用cat /proc/meminfo | grep Shmem查宿主机级汇总） - 生产环境建议按角色分级：训练节点 ≥2GB，推理服务 ≥1GB，协调/调度类服务 ≥512MB
进阶：跨容器共享 shm（非默认行为）
标准 shm_size 仅扩容本容器私有 /dev/shm，不实现容器间互通。若需真正共享（如 worker 与监控 sidecar 共读指标缓冲区），需配合 --ipc 模式：
- 在 Compose 中无法直接表达
--ipc=container:，需改用docker run或自定义网络模式 - 更安全的替代方案是挂载同一
tmpfs卷：volumes: shared-shm: driver: local driver_opts: type: tmpfs device: tmpfs o: size=2g,uid=1001,gid=1001然后在各 service 下通过volumes挂载到/shared-shm，由应用自行管理路径
