直接调大--shm-size是最有效解决方式，因Docker默认64MB /dev/shm不足，易致No space left on device等错误；需按场景分级配置（如Web服务128MB、PyTorch训练2GB起），并通过df -h /dev/shm验证。
直接调大 --shm-size 是最有效、最快速的解决方式。docker 默认的 64mb /dev/shm 对高并发或高性能应用（如 chrome headless、tensorflow 多线程推理、postgresql 连接池、视频转码）远远不够，容易触发 no space left on device 或进程异常退出。
为什么 shm-size 小会导致“内存映射溢出”
这里的“溢出”并非传统意义的堆内存耗尽，而是 /dev/shm 这个基于 tmpfs 的内存文件系统空间不足。它被大量用于：
- 进程间高频数据交换（如 Web 服务与缓存模块共享会话）
- 多线程/多进程模型下的临时缓冲区（如 OpenCV 图像处理、FFmpeg 帧缓存）
- 浏览器渲染引擎（Chrome/Chromium 的沙箱通信依赖大块 shm）
- 机器学习框架内部张量共享（尤其是 PyTorch DataLoader 多 worker 场景）
一旦写入超过 64MB，内核拒绝 mmap 映射请求，应用表现为“无法创建线程”“共享内存段分配失败”或静默崩溃。
如何合理设置 --shm-size
不建议盲目设为 2g 或更大，应结合场景分级配置：
- Web API / 轻量服务：128MB～256MB 已足够
- Headless Chrome 渲染服务：至少 512MB，推荐 1GB
- 视频转码（FFmpeg + GPU 加速）：1GB～2GB
- TensorFlow/PyTorch 训练或批量推理（多 DataLoader worker）：2GB 起步，视 batch size 和 num_workers 调整
命令示例：
docker run -d \ --shm-size=1g \ --name video-encoder \ video-processor:latest
进阶：跨容器共享 shm 或绕过限制
若需多个容器协同访问同一块共享内存（如微服务间低延迟通信），单靠增大各自 shm-size 不够，还需 IPC 配置：
- 让容器 B 共享容器 A 的 IPC 命名空间：
--ipc=container:A - 完全复用宿主机 shm（仅限可信、性能敏感环境）：
--ipc=host - 手动挂载宿主机 shm（更可控）：
--mount type=bind,source=/dev/shm,target=/dev/shm
注意：--ipc=host 会削弱隔离性，生产环境慎用；--mount 方式可配合 rw 权限和 tmpfs 选项精细控制大小与行为。
验证与排查方法
容器启动后，进入容器检查实际生效值：
docker exec -it myapp df -h /dev/shm # 输出应显示 Size 接近你设定的值（如 1.0G） <p>ls -ld /dev/shm</p><h1>权限应为 drwxrwxrwt，确保应用有读写权限
若仍报错，检查是否应用本身设置了额外 shm 限制（如 Chromium 的 --disable-dev-shm-usage 会退回到 /tmp，但性能下降）；也需确认未同时启用 --memory 限制过严，导致整体内存不足间接影响 shm 分配。
