为何top与docker stats报告的CPU利用率存在差异？

• docker stats的CPU %理解完全正确：这个指标的逻辑就是「容器用了多少核×100%」，100%对应宿主机1核跑满。你给PostgreSQL容器设了--cpus 16，所以1595.06%确实意味着容器的CPU消耗已经接近16核的满负荷上限。
• top的核利用率理解也没问题：当你按1切换到单核心视图时，每个核显示的65%，是这个核心在统计周期内的总负载占比——简单说就是该核有65%的时间在干活，剩下35%闲着。

这俩工具的统计逻辑、维度甚至依赖的底层环境都不一样，具体原因可能是以下几种：

1. 虚拟机被物理机限制了CPU配额
   你是在虚拟机上跑的Docker Swarm，如果物理宿主机给这个虚拟机的CPU配额不是满额16核（比如只允许它用10核的实际算力），就会出现这种矛盾：
   • docker stats是基于虚拟机内部配置的16核来计算的，所以会显示接近16核满负荷的数值；
   • 但虚拟机实际能拿到的物理CPU算力有限，top显示的是虚拟机真实能输出的负载比例，10/16≈62.5%，和你看到的65%基本吻合。
2. 统计周期不一样
   • docker stats默认是10秒的统计窗口，算的是这段时间的平均CPU使用率；
   • top默认3秒刷新一次，采样窗口短很多。如果PostgreSQL的CPU负载是脉冲式的（比如短时间跑满16核，其余时间空闲），docker stats的长周期平均值会接近满负荷，而top刚好抓到低负载时段，就会显示65%的核利用率。
3. 统计范围不同
   • docker stats只盯着容器内部的进程算CPU消耗，不管虚拟机上的其他负载；
   • top算的是整个虚拟机的所有负载，包括系统内核、后台进程、Docker守护进程这些。如果虚拟机上还有其他活儿在跑，就会把单核心的利用率摊薄。
4. CPU调度的不均匀性
   就算你给容器开了16核权限，Linux内核的调度器也不一定会让容器进程均匀占满所有核。比如容器进程集中在10个核上跑满，剩下6个核要么被系统进程用，要么闲着，docker stats把所有核的容器消耗加起来接近1600%，但top看单个核的平均利用率就会是（10×100% +6×0%）/16≈62.5%，和你看到的65%一致。

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