树莓派3上Docker为何限制容器CPU使用率至100%？

我之前在树莓派上跑Docker容器里的CPU密集型程序时，也碰到过性能打折扣的情况，结合你的场景——程序在宿主机能跑到130% CPU占用、32fps压缩帧率，容器内却达不到这个表现，咱们一步步来排查和解决：

1. 先检查Docker的CPU资源限制 #

默认情况下Docker容器理论上能使用宿主机全部CPU，但有时候因为配置或者cgroup的限制，会导致程序没法充分利用算力：

• 先查看容器的CPU配置：执行docker inspect <容器ID或名称> | grep -A 10 "Cpu"，重点看CpuQuota、CpuPeriod和CpuShares这几个参数。如果CpuQuota数值低于100000（对应1核的算力），那肯定会限制程序的CPU使用。
• 如果发现有限制，启动容器时直接放开核心权限：比如用docker run --cpus 4 --device /dev/video0 -d <你的镜像名>，--cpus 4表示允许容器使用全部4核，--device用来挂载摄像头设备（这个很重要，后面会说）。

2. 确认摄像头设备的访问权限 #

你的程序依赖摄像头，要是容器内没法高效访问摄像头，也会间接拖慢压缩环节的性能：

• 启动容器时必须挂载摄像头设备：一定要加上--device /dev/video0（如果你的摄像头是其他编号，换成对应的就行），不然程序可能会用模拟输入或者低效的方式获取画面，导致CPU空转或者帧率上不去。
• 进入容器检查设备权限：执行docker exec -it <容器ID> ls -l /dev/video0，如果权限不对，可以尝试用--user root启动容器，或者在宿主机先调整/dev/video0的权限再挂载。

3. 优化容器的CPU调度器适配 #

树莓派的ARM架构对Docker默认的CFS调度器可能不太友好，导致CPU调度效率低：

• 可以尝试用实时调度器测试：启动容器时加上--cpu-rt-runtime 950000 --ulimit rtprio=99（前提是宿主机开启了实时权限，一般Raspbian默认支持），这样程序能获得更高的CPU调度优先级，减少等待时间。
• 另外，检查宿主机的cgroup版本：Raspbian一般用cgroup v1，要是你升级过系统到cgroup v2，可能需要调整Docker的cgroup驱动配置，具体可以修改/etc/docker/daemon.json里的"exec-opts": ["native.cgroupdriver=cgroupfs"]，然后重启Docker服务。

4. 确保镜像依赖是ARM优化过的 #

如果你的Docker镜像用的是通用Debian或Ubuntu镜像，里面的压缩库（比如ffmpeg、libjpeg这类）可能没有针对树莓派的ARMv7架构优化，导致压缩效率比宿主机低：

• 尽量用Raspbian官方镜像做基础：比如raspbian/bullseye，这个镜像里的所有依赖都是针对树莓派优化过的，能充分利用NEON指令集提升压缩速度。
• 编译程序时开启ARM优化：如果是自己编译程序，在容器内编译时加上编译参数-march=armv7-a -mfpu=neon -mfloat-abi=hard，让程序直接调用树莓派的硬件加速指令，压缩效率会明显提升。

5. 对比宿主机与容器的CPU占用细节 #

用docker stats查看容器的整体CPU使用率，同时在宿主机用htop（比top更直观）找到容器内的程序进程，对比宿主机直接运行时的CPU占用：

• 如果容器内程序的CPU占用始终上不去，可能是Docker的安全隔离机制限制了性能，可以临时加--security-opt seccomp=unconfined启动容器（注意这个会降低容器的安全性，只用来测试），看看性能是否回升，要是回升了再针对性调整seccomp规则。

按照上面的步骤一步步排查，应该能找到容器内性能下降的原因，把压缩帧率提上去。

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